Kubernetes入门 四、Pod核心

什么是Pod

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

Pod是在K8s集群中运行部署应用或服务的最小单元，它是可以支持多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。Pod对多容器的支持是K8s最基础的设计理念。比如你运行一个操作系统发行版的软件仓库，一个Nginx容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是他们一块儿工作才能提供一个微服务；这种情况下，不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。

Pod是K8s集群中所有业务类型的基础，可以看作运行在K8s集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。目前K8s中的业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet和StatefulSet，本文后面会一一介绍。

Pod与容器不同

前面我们知道，容器是 Pod 中实际运行应用程序的载体。

那为什么不直接使用容器，还要有Pod这个东西呢？

主要有以下几个方面的考虑：

• 多容器协同：一个 Pod 中可以运行多个容器，这些容器可以共享同一个网络命名空间、存储卷等资源。这使得在一个 Pod 内部的多个容器之间实现通信和数据共享变得更加方便。比如，你可以在同一个 Pod 中运行一个应用程序容器和一个辅助容器，用于收集日志或处理数据。
• 共享网络和存储命名空间：在同一个 Pod 中的容器可以共享相同的 IP 地址和端口空间，这对于容器之间的通信非常有用。此外，它们还可以共享同一份存储卷，这意味着它们可以在相同的文件系统中读写数据，从而实现数据共享。
• 调度和伸缩：K8s 通常按照 Pod 来进行调度和伸缩。当你定义一个 Deployment 或者 Replication Controller 时，你实际上是在定义 Pod 的副本数量。K8s 会自动创建和管理这些 Pod 的实例，确保它们按照所需的数量在集群中运行。
• 生命周期管理：Pod 提供了更高级别的生命周期管理。当一个 Pod 被创建时，它的生命周期与其内部的所有容器密切相关。这意味着如果一个容器失败，整个 Pod 可能会重新启动。此外，Pod 还提供了一些钩子（lifecycle hooks），可以在容器启动之前或之后执行特定的操作，以便实现更复杂的初始化或清理逻辑。
• 资源共享和限制：Pod 允许你在多个容器之间共享资源，比如 CPU 和内存。你可以设置资源请求和限制，以确保 Pod 中的容器不会相互干扰，从而实现更好的资源管理。

Pod如何管理多个容器

Pod 中可以同时运行多个容器。同一个 Pod 中的容器会自动的分配到同一个 node 上。同一个 Pod 中的容器共享资源、网络环境，它们总是被同时调度，在一个 Pod 中同时运行多个容器是一种比较高级的用法，只有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如，你有一个容器作为 web 服务器运行，需要用到共享的 volume，有另一个“sidecar”容器来从远端获取资源更新这些文件。

一些 Pod 有 init 容器和应用容器。 在应用程序容器启动之前，运行初始化容器。

Pod 天生地为其成员容器提供了两种共享资源：网络和存储。

Pod的管理-工作负载

通常不需要直接创建 Pod，而是使用诸如 Deployment 或 Job这类工作负载资源来创建 Pod。

工作负载是运行的 Kubernetes 上的一个应用程序。

一个应用很复杂，可能由单个组件或者多个组件共同完成。我们可以用一组 Pod 来描述一个应用，也就是一个工作负载，而 Pod 是一组容器。

换言之，工作负载控制一组 Pod ，Pod 控制一组容器（如：Deployment【工作负载】部署 3 个副本的 nginx-pod ，每个 nginx-pod 里面是真正的 nginx 容器）。

工作负载能让 Pod 拥有自愈能力。我们主要研究不同的工作负载如何控制 Pod 的行为。

K8s中的资源清单

在 K8s 中，所有的资源都可以使用一个 yaml 文件来创建。下面是资源对应的yaml的配置项：

参数名	类型	字段说明
apiVersion	String	K8S APl 的版本，可以用 kubectl api versions 命令查询
kind	String	yam 文件定义的资源类型和角色
metadata	Object	元数据对象，下面是它的属性
metadata.name	String	元数据对象的名字，比如 pod 的名字
metadata.namespace	String	元数据对象的命名空间
Spec	Object	详细定义对象
spec.containers[]	list	定义 Spec 对象的容器列表
spec.containers[].name	String	为列表中的某个容器定义名称
spec.containers[].image	String	为列表中的某个容器定义需要的镜像名称
spec.containers[].imagePullPolicy	string	定义镜像拉取策略，有 Always、Never、IfNotPresent 三个值可选 - Always（默认）：意思是每次都尝试重新拉取镜像 - Never：表示仅适用本地镜像 - IfNotPresent：如果本地有镜像就使用本地镜像，没有就拉取在线镜像。
spec.containers[].command[]	list	指定容器启动命令，因为是数组可以指定多个，不指定则使用镜像打包时使用的启动命令。
spec.containers[].args[]	list	指定容器启动命令参数，因为是数组可以指定多个。
spec.containers[].workingDir	string	指定容器的工作目录
spec.containers[].volumeMounts[]	list	指定容器内部的存储卷配置
spec.containers[].volumeMounts[].name	string	指定可以被容器挂载的存储卷的名称
spec.containers[].volumeMounts[].mountPath	string	指定可以被容器挂载的存储卷的路径
spec.containers[].volumeMounts[].readOnly	string	设置存储卷路径的读写模式，ture 或者 false，默认是读写模式
spec.containers[].ports[]	list	指定容器需要用到的端口列表
spec.containers[].ports[].name	string	指定端口的名称
spec.containers[].ports[].containerPort	string	指定容器需要监听的端口号
spec.containers[].ports[].hostPort	string	指定容器所在主机需要监听的端口号，默认跟上面 containerPort 相同，注意设置了 hostPort 同一台主机无法启动该容器的相同副本（因为主机的端口号不能相同，这样会冲突）
spec.containers[].ports[].protocol	string	指定端口协议，支持 TCP 和 UDP，默认值为 TCP
spec.containers[].env[]	list	指定容器运行前需设置的环境变量列表
spec.containers[].env[].name	string	指定环境变量名称
spec.containers[].env[].value	string	指定环境变量值
spec.containers[].resources	Object	指定资源限制和资源请求的值（这里开始就是设置容器的资源上限）
spec.containers[].resources.limits	Object	指定设置容器运行时资源的运行上限
spec.containers[].resources.limits.cpu	string	指定 CPU 的限制，单位为 Core 数，将用于 docker run –cpu-shares 参数
spec.containers[].resources.limits.memory	string	指定 mem 内存的限制，单位为 MIB、GiB
spec.containers[].resources.requests	Object	指定容器启动和调度时的限制设置
spec.containers[].resources.requests.cpu	string	CPU请求，单位为core数，容器启动时初始化可用数量
spec.containers[].resources.requests.memory	string	内存请求，单位为MIB、GiB，容器启动的初始化可用数量
spec.restartPolicy	string	定义 pod 的重启策略，可选值为 Always、OnFailure、Never，默认值为 Always。 - Always：pod 一旦终止运行，则无论容器是如何终止的，kubelet 服务都将重启它。 - OnFailure：只有 pod 以非零退出码终止时，kubelet 才会重启该容器。如果容器正常结束（退出码为0），则 kubectl 将不会重启它。 - Never：Pod 终止后，kubelet 将退出码报告给 master，不会重启该 pod
spec.nodeSelector	Object	定义 Node 的 label 过滤标签，以 key：value 格式指定
spec.imagePullSecrets	Object	定义 pull 镜像时使用 secret 名称，以 name：secretkey 格式指定
spec.hostNetwork	Boolean	定义是否使用主机网络模式，默认值为 false。设置 true 表示使用宿主机网络，不使用 docker 网桥，同时设置了 true将无法在同一台宿主机上启动第二个副本

创建使用Pod

可以使用 Deployment 等各种工作负载的 yaml 文件创建 Pod ，也可以直接创建 Pod（实际生产中不推荐） 。

创建 Pod 也可以使用 yaml 配置文件。或者使用 kubectl run 在命令行创建 Pod（不常用）。

直接创建Pod

首先创建一个yaml文件，来定义Pod，用来创建一个nginx服务，yaml如下：

apiVersion: v1 # api 文档版本
kind: Pod  # 资源对象类型，也可以配置为像Deployment、StatefulSet这一类的对象
metadata: # Pod 相关的元数据，用于描述 Pod 的数据
  name: nginx-demo # Pod 的名称
  labels: # 定义 Pod 的标签
    type: app # 自定义 label 标签，名字为 type，值为 app
    test: 1.0.0 # 自定义 label 标签，描述 Pod 版本号
  namespace: 'default' # 命名空间的配置
spec: # 期望 Pod 按照这里面的描述进行创建
  containers: # 对于 Pod 中的容器描述
  - name: nginx # 容器的名称
    image: nginx:1.7.9 # 指定容器的镜像
    imagePullPolicy: IfNotPresent # 镜像拉取策略，指定如果本地有就用本地的，如果没有就拉取远程的
    command: # 指定容器启动时执行的命令
    - nginx
    - -g
    - 'daemon off;' # nginx -g 'daemon off;'
    workingDir: /usr/share/nginx/html # 定义容器启动后的工作目录
    ports:
    - name: http # 端口名称
      containerPort: 80 # 描述容器内要暴露什么端口
      protocol: TCP # 描述该端口是基于哪种协议通信的
    env: # 环境变量
    - name: JVM_OPTS # 环境变量名称
      value: '-Xms128m -Xmx128m' # 环境变量的值
    resources:
      requests: # 最少需要多少资源
        cpu: 100m # 限制 cpu 最少使用 0.1 个核心
        memory: 128Mi # 限制内存最少使用 128兆
      limits: # 最多可以用多少资源
        cpu: 200m # 限制 cpu 最多使用 0.2 个核心
        memory: 256Mi # 限制 最多使用 256兆
  restartPolicy: OnFailure # 重启策略，只有失败的情况才会重启

创建完文件后，执行如下命令创建pod：

kubectl apply -f nginx-demo.yaml
# 创建成功时打印如下：
# pod/nginx-demo created

创建成功后，可以查看Pod：

kubectl get po

结果如下：

NAME         READY   STATUS    RESTARTS   AGE
nginx-demo   1/1     Running   0          29s

注意只有READY了这个pod才是真正可用的。

还可以查看更多信息：

kubectl get po -o wide

结果如下：

NAME         READY   STATUS    RESTARTS   AGE   IP          NODE             NOMINATED NODE   READINESS GATES
nginx-demo   1/1     Running   0          12m   10.1.0.10   docker-desktop   <none>           <none>

同时我们可以使用discribe查看pod的详细信息：

kubectl describe po nginx-demo

结果如下：

Name:             nginx-demo
Namespace:        default
Priority:         0
Service Account:  default
Node:             docker-desktop/192.168.65.4
Start Time:       Thu, 10 Aug 2023 21:40:07 +0800
Labels:           test=1.0.0
                  type=app
Annotations:      <none>
Status:           Running
IP:               10.1.0.10
IPs:
  IP:  10.1.0.10
Containers:
  nginx:
    Container ID:  docker://0e3d50bbaab39c6f34f0bdbbdfc8edea7e40a0d2b7650701bb656b90606ef973
    Image:         nginx:1.7.9
    Image ID:      docker-pullable://nginx@sha256:e3456c851a152494c3e4ff5fcc26f240206abac0c9d794affb40e0714846c451
    Port:          80/TCP
    Host Port:     0/TCP
    Command:
      nginx
      -g
      daemon off;
    State:          Running
      Started:      Thu, 10 Aug 2023 21:40:25 +0800
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     200m
      memory:  256Mi
    Requests:
      cpu:     100m
      memory:  128Mi
    Environment:
      JVM_OPTS:  -Xms128m -Xmx128m
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-hxd9m (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  kube-api-access-hxd9m:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  4m55s  default-scheduler  Successfully assigned default/nginx-demo to docker-desktop
  Normal  Pulling    4m55s  kubelet            Pulling image "nginx:1.7.9"
  Normal  Pulled     4m37s  kubelet            Successfully pulled image "nginx:1.7.9" in 17.155282967s (17.155348675s including waiting)
  Normal  Created    4m37s  kubelet            Created container nginx
  Normal  Started    4m37s  kubelet            Started container nginx

最下面有这个pod发生的事件Events，可以看到整个pod创建的过程。主要有如下几步：

1. 第1行：default-scheduler为我们分配节点，Successfully assigned default/nginx-demo to docker-desktop
2. 第2行：kubelet执行拉取镜像，Pulling image “nginx:1.7.9”
3. 第3行：kubelet成功拉取了镜像
4. 第4行：kubelet执行创建容器，Created container nginx
5. 第5行：kubelet启动了容器

这个事件对我们后面学习和排错非常重要。

使用 Deployment 创建Pod

创建如下nginx-deployment-demo.yaml文件，内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
  labels:
    app: nginx-deploy
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2  # 指定副本数
  template:
    metadata:
      labels:
        app: nginx  # 标签，用来选择资源使用
    spec:
      containers:
      - name: my-nginx  # 容器名字
        image: nginx  # 镜像名
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

执行命令：

kubectl apply -f nginx-deployment-demo.yaml

创建成功后打印如下：

deployment.apps/nginx-test created

我们可以看下创建的资源：

kubectl get deploy

打印如下：

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
nginx-test   2/2     2            2           99s

查看我们创建的pod，可使用我们yaml里定义的标签选择来过滤：

 kubectl get pods -o wide -l app=nginx

如下：

NAME                         READY   STATUS    RESTARTS   AGE   IP          NODE             NOMINATED NODE   READINESS GATES
nginx-test-b65fff6d9-jhcgj   1/1     Running   0          10m   10.1.0.17   docker-desktop   <none>           <none>
nginx-test-b65fff6d9-qkmgl   1/1     Running   0          10m   10.1.0.16   docker-desktop   <none>           <none>

同时我们在yaml里定义了副本数是2，如果我们删除一个，如下：

kubectl delete pod nginx-test-b65fff6d9-qkmgl

再次查询pod结果如下：

NAME                         READY   STATUS    RESTARTS   AGE   IP          NODE             NOMINATED NODE   READINESS GATES
nginx-test-b65fff6d9-j7n24   1/1     Running   0          28s   10.1.0.18   docker-desktop   <none>           <none>
nginx-test-b65fff6d9-jhcgj   1/1     Running   0          14m   10.1.0.17   docker-desktop   <none>           <none>

可以看到有重新创建了一个pod name为nginx-test-b65fff6d9-j7n24。因此可以知道，通过 deployment 管理的 pod，可以确保 pod 始终维持在指定副本数量，并且使用两个pod效果是一样的。

环境变量

环境变量为容器提供了一些重要的资源，包括容器和 Pod 的基本信息以及集群中服务的信息等：

(1) hostname

HOSTNAME 环境变量保存了该 Pod 的 hostname。

（2）容器和 Pod 的基本信息

Pod 的名字、命名空间、IP 以及容器的计算资源限制等可以以 Downward API 的方式获取并存储到环境变量中。

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: ["sh", "-c"]
      args:
      - env
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      env:
        - name: MY_NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: MY_POD_SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              fieldPath: spec.serviceAccountName
        - name: MY_CPU_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.cpu
        - name: MY_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.cpu
        - name: MY_MEM_REQUEST
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: requests.memory
        - name: MY_MEM_LIMIT
          valueFrom:
            resourceFieldRef:
              containerName: test-container
              resource: limits.memory
  restartPolicy: Never

(3) 集群中服务的信息

容器的环境变量中还可以引用容器运行前创建的所有服务的信息，比如默认的 kubernetes 服务对应以下环境变量：

KUBERNETES_PORT_443_TCP_ADDR=10.0.0.1
KUBERNETES_SERVICE_HOST=10.0.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT=tcp://10.0.0.1:443
KUBERNETES_PORT_443_TCP=tcp://10.0.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_PORT=443

由于环境变量存在创建顺序的局限性（环境变量中不包含后来创建的服务），推荐使用 DNS 来解析服务。

重启策略

支持三种 RestartPolicy

• Always：当容器失效时，由Kubelet自动重启该容器。RestartPolicy的默认值。
• OnFailure：当容器终止运行且退出码不为0时由Kubelet重启。
• Never：无论何种情况下，Kubelet都不会重启该容器。

注意，这里的重启是指在 Pod 所在 Node 上面本地重启，并不会调度到其他 Node 上去。

镜像拉取策略

支持三种 ImagePullPolicy

• Always：不管本地镜像是否存在都会去仓库进行一次镜像拉取。校验如果镜像有变化则会覆盖本地镜像，否则不会覆盖。
• Never：只是用本地镜像，不会去仓库拉取镜像，如果本地镜像不存在则Pod运行失败。
• IfNotPresent：只有本地镜像不存在时，才会去仓库拉取镜像。ImagePullPolicy的默认值。

注意：

• 默认为 IfNotPresent，但 :latest 标签的镜像默认为 Always。
• 拉取镜像时 docker 会进行校验，如果镜像中的 MD5 码没有变，则不会拉取镜像数据。
• 生产环境中应该尽量避免使用 :latest 标签，而开发环境中可以借助 :latest 标签自动拉取最新的镜像。

访问 DNS 的策略

通过设置 dnsPolicy 参数，设置 Pod 中容器访问 DNS 的策略

• ClusterFirst：优先基于 cluster domain （如 default.svc.cluster.local） 后缀，通过 kube-dns 查询 (默认策略)
• Default：优先从 Node 中配置的 DNS 查询

资源限制

Kubernetes 通过 cgroups 限制容器的 CPU 和内存等计算资源，包括 requests（请求，调度器保证调度到资源充足的 Node 上，如果无法满足会调度失败）和 limits（上限）等：

• spec.containers[].resources.limits.cpu：CPU 上限，可以短暂超过，容器也不会被停止
• spec.containers[].resources.limits.memory：内存上限，不可以超过；如果超过，容器可能会被终止或调度到其他资源充足的机器上
• spec.containers[].resources.limits.ephemeral-storage：临时存储（容器可写层、日志以及 EmptyDir 等）的上限，超过后 Pod 会被驱逐
• spec.containers[].resources.requests.cpu：CPU 请求，也是调度 CPU 资源的依据，可以超过
• spec.containers[].resources.requests.memory：内存请求，也是调度内存资源的依据，可以超过；但如果超过，容器可能会在 Node 内存不足时清理
• spec.containers[].resources.requests.ephemeral-storage：临时存储（容器可写层、日志以及 EmptyDir 等）的请求，调度容器存储的依据

比如 nginx 容器请求 30% 的 CPU 和 56MB 的内存，但限制最多只用 50% 的 CPU 和 128MB 的内存：

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  containers:
    - image: nginx
      name: nginx
      resources:
        requests:
          cpu: "300m"
          memory: "56Mi"
        limits:
          cpu: "500m"
          memory: "128Mi"

注意

• CPU 的单位是 CPU 个数，可以用 millicpu (m) 表示少于 1 个 CPU 的情况，如 500m = 500millicpu = 0.5cpu，而一个 CPU 相当于
  • AWS 上的一个 vCPU
  • GCP 上的一个 Core
  • Azure 上的一个 vCore
  • 物理机上开启超线程时的一个超线程
• 内存的单位则包括 E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki 等。
• 从 v1.10 开始，可以设置 kubelet ----cpu-manager-policy=static 为 Guaranteed（即 requests.cpu 与 limits.cpu 相等）Pod 绑定 CPU（通过 cpuset cgroups）。

初始化容器

Pod 能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的 Init 容器。Init 容器在所有容器运行之前执行（run-to-completion），常用来初始化配置。

如果为一个 Pod 指定了多个 Init 容器，那些容器会按顺序一次运行一个。 每个 Init 容器必须运行成功，下一个才能够运行。 当所有的 Init 容器运行完成时，Kubernetes 初始化 Pod 并像平常一样运行应用容器。

初始化容器有很多的应用场景，下面列出的是最常见的几个：

• 提供主容器镜像中不具备的工具程序或自定义代码。
• 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足。

下面是一个 Init 容器的示例：

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
  # These containers are run during pod initialization
  initContainers:
  - name: install
    image: busybox
    command:
    - wget
    - "-O"
    - "/work-dir/index.html"
    - http://kubernetes.io
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"
  dnsPolicy: Default
  volumes:
  - name: workdir
    emptyDir: {}

因为 Init 容器具有与应用容器分离的单独镜像，使用 init 容器启动相关代码具有如下优势：

• 它们可以包含并运行实用工具，出于安全考虑，是不建议在应用容器镜像中包含这些实用工具的。
• 它们可以包含使用工具和定制化代码来安装，但是不能出现在应用镜像中。例如，创建镜像没必要 FROM 另一个镜像，只需要在安装过程中使用类似 sed、 awk、 python 或 dig 这样的工具。
• 它们在应用容器启动之前运行完成，然而应用容器并行运行，所以 Init 容器提供了一种简单的方式来阻塞或延迟应用容器的启动，直到满足了一组先决条件。
• 它们使用 Linux Namespace，所以对应用容器具有不同的文件系统视图。因此，它们能够具有访问 Secret 的权限，而应用容器不能够访问。

临时容器（了解）

临时容器是一种特殊的容器，该容器可以在现有的 Pod 中临时运行，以便完成我们发起的操作，比如故障排查。我们应该使用临时容器来检查服务，而不是用临时容器来构建应用程序。

Pod 是 Kubernetes 集群进行管理的最小单元，由于 Pod 是一次性且可以替换的，因此 Pod 一旦被创建，就无法将容器加入到Pod 中。而且，我们通常使用 Deployment 来删除并替换Pod。但是，有的时候我们需要检查现有 Pod 的状态，比如对难以复现的故障进行排查。在这些场景中，可以在现有 Pod 中运行临时容器来检查其状态并运行任意命令。

临时容器在目前的 Kubernetes 版本是 beta 。

和常规容器一样，将临时容器添加到Pod后，不能更改或删除临时容器。