一种进入Pod容器网络的方法

背景

1、k8s+docker环境中,pod容器正常启动,但是因容器镜像中没有sh/bash等工具无法通过kubectl exec登录容器(如coredns镜像),或者能通过kubectl exec登录容器,但是容器内没有ping、telnet、curl、tcpdump等工具。
2、有登录容器宿主机的权限,且该宿主机上有相关工具。

[root@VM-0-12-centos ~]# hostname -I
10.72.0.12 169.254.32.1 172.16.0.1 
[root@VM-0-12-centos ~]# kubectl get node
NAME         STATUS   ROLES    AGE   VERSION
10.72.0.12   Ready    <none>   9m    v1.20.6-tke.12
[root@VM-0-12-centos ~]# kubectl get pod -A -owide | grep coredns
kube-system   coredns-78964c5667-6ht4c              1/1     Running   1          11m     172.16.0.6   10.72.0.12   <none>           <none>
[root@VM-0-12-centos ~]# kubectl -n kube-system exec -ti coredns-78964c5667-6ht4c -- sh
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "sh": executable file not found in $PATH: unknown
command terminated with exit code 126
[root@VM-0-12-centos ~]# kubectl -n kube-system exec -ti coredns-78964c5667-6ht4c -- bash
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "bash": executable file not found in $PATH: unknown
command terminated with exit code 126
[root@VM-0-12-centos ~]#

解决方案

1. 找到容器id

kubectl -n {namespace} get pod {podName} -oyaml | grep containerID -A 1

使用kubectl命令从pod的yaml中找到容器id,注意:一个pod可能包含多个容器,这里需要根据对应的镜像名称确定选择哪个容器,如下示例所示,coredns镜像对应的容器为id6008ed69fd26d235d7d674966705815c1dccee9dde72e526507fd0f026ab819b。

[root@VM-0-12-centos ~]# kubectl -n kube-system get pod coredns-78964c5667-6ht4c -oyaml | grep containerID -A 1
  - containerID: docker://6008ed69fd26d235d7d674966705815c1dccee9dde72e526507fd0f026ab819b
    image: ccr.ccs.tencentyun.com/library/coredns:1.6.2
2. 根据容器id找到容器进程号

docker inspect {containerID} | grep \"Pid\"

对docker容器而言,容器的本质就是宿主机上的一个特殊进程,因此可以登录到pod所在的宿主机上使用docker inspect命令从容器信息里找到进程id。

[root@VM-0-12-centos ~]# docker inspect 6008ed69fd26d235d7d674966705815c1dccee9dde72e526507fd0f026ab819b | grep \"Pid\"
            "Pid": 3425,
3. 根据容器进程号进入容器网络命名空间

nsenter -t {pid} -n

使用nsenter命令进入容器网络命名空间,-t参数是指定目标进程号,-n参数是进入目标进程的网络命名空间。

[root@VM-0-12-centos ~]# nsenter -t 3425 -n
[root@VM-0-12-centos ~]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.0.6  netmask 255.255.255.192  broadcast 172.16.0.63
        ether ce:0c:d5:6f:69:8a  txqueuelen 0  (Ethernet)
        RX packets 1263  bytes 141931 (138.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1197  bytes 206822 (201.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 17910  bytes 1429218 (1.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 17910  bytes 1429218 (1.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@VM-0-12-centos ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.0.1      0.0.0.0         UG    0      0        0 eth0
172.16.0.0      0.0.0.0         255.255.255.192 U     0      0        0 eth0
[root@VM-0-12-centos ~]# curl
curl: try 'curl --help' or 'curl --manual' for more information
[root@VM-0-12-centos ~]# exit
logout
[root@VM-0-12-centos ~]#

微信公众号卡巴斯同步发布,欢迎大家关注。

<think>好的,我现在需要回答用户的问题:“一个pod中可以有多个容器吗?”首先,我需要确认用户是在Kubernetes的上下文中提问的,因为“Pod”是Kubernetes中的概念。用户之前的提问涉及到CRI(容器运行时接口),这可能表明他们对Kubernetes有一定了解,或者至少是在云计算或容器编排的领域工作。 接下来,我需要回忆KubernetesPod的基本定义和结构。PodKubernetes中最小的可部署单元,通常用来托管一个主容器,但确实支持多个容器共存。需要明确说明这一点,并解释为什么会有这样的设计。 然后,要列举多个容器共存于同一个Pod的常见用例,比如边车模式、适配器模式、Ambassador模式等,每个模式都需要简要说明其用途和例子。例如,边车容器可以用来处理日志收集或网络代理,这样主应用容器可以专注于业务逻辑。 还要提到这些容器之间的资源共享,比如共享存储卷和网络命名空间,这样它们可以通过localhost直接通信,共享相同的IP和端口空间。这是多容器Pod的一个重要优势,但同时也需要注意资源竞争的问题。 另外,需要强调虽然可以运行多个容器,但通常建议每个Pod只运行一个主应用容器,除非有紧密的协作需求。这有助于保持模块化和可维护性,符合微服务架构的最佳实践。 还要考虑用户可能的疑问,比如如何管理多个容器的启动顺序、生命周期以及健康检查。可能需要简要提及Init容器,它们在主容器启动前运行,用于准备环境,这也是多容器Pod一种应用场景。 最后,确保回答结构清晰,分点说明,使用例子和场景帮助用户理解,同时语言要简洁明了,避免技术术语过多,必要时进行解释。需要确认所有信息准确,比如Kubernetes的版本兼容性,但可能不需要特别指出,除非有版本差异。</think>**是的,Kubernetes 中一个 Pod 可以包含多个容器**。这是 Kubernetes 架构的重要设计特性,以下为详细说明: --- ### **核心概念** 1. **Pod 的本质** - PodKubernetes 的最小调度单元,**本质是共享资源的容器组** - 同一 Pod 中的容器: - 共享相同的网络命名空间(同一 IP 地址,可通过 `localhost` 直接通信) - 共享存储卷(Volumes) - 具有统一的生命周期(同时创建/销毁) 2. **典型多容器场景** | 模式 | 作用 | 示例 | |---------------|----------------------------------------|-----------------------------------| | **边车(Sidecar)** | 扩展主容器功能 | 日志收集容器 + Web 服务容器 | | **适配器(Adapter)** | 标准化数据格式 | 协议转换容器 + 数据库容器 | | **大使(Ambassador)** | 代理网络请求 | 代理容器 + 后端服务容器 | | **Init 容器** | 在主容器启动前执行预处理任务 | 数据库迁移容器 + 应用容器 | --- ### **实际应用示例** #### 场景:Web 服务与日志收集 ```yaml apiVersion: v1 kind: Pod metadata: name: web-logger spec: volumes: - name: shared-logs emptyDir: {} containers: - name: web-server image: nginx volumeMounts: - name: shared-logs mountPath: /var/log/nginx - name: log-processor image: fluentd volumeMounts: - name: shared-logs mountPath: /logs ``` **关键点**: 1. 两个容器通过 `shared-logs` 卷共享日志目录 2. Nginx 容器专注处理 Web 请求 3. Fluentd 容器实时处理日志(无需修改主应用) --- ### **设计建议** 1. **何时使用多容器** - 需要紧密协作(如共享内存数据) - 功能扩展但不愿修改主应用镜像(如监控代理) - 临时任务(如数据预加载) 2. **何时避免** - 容器之间需要独立扩缩容 - 不同更新频率的组件 - 非紧密耦合的服务(应采用独立 Pod + Service 通信) --- ### **操作注意事项** 1. **资源管理**:需为每个容器单独配置 CPU/内存限制 ```yaml containers: - name: app resources: limits: memory: "128Mi" cpu: "500m" - name: sidecar resources: limits: memory: "64Mi" cpu: "250m" ``` 2. **启动顺序控制**:使用 Init 容器确保依赖项就绪 3. **健康检查**:需为每个容器单独配置 liveness/readiness 探针 --- **总结**:多容器 Pod 实现了 **"功能内聚,进程隔离"** 的设计哲学,既能保持单一职责原则,又能通过资源共享提升效率,是 Kubernetes 灵活性的重要体现。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值