NexaGrid技术博客

NexaGrid技术博客

Kubernetes从基础到实战应用(Pod)

2025-06-24
Kubernetes从基础到实战应用(Pod)

简单认识Pod

[Pods|Kubernetes] https://kubernetes.io/docs/concepts/workloads/pods/

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

Pod(就像在鲸鱼荚或者豌豆荚中)是一组(一个或多个) 容器; 这些容器共享存储、网络、以及怎样运行这些容器的规约。 Pod 中的内容总是并置(colocated)的并且一同调度,在共享的上下文中运行。

Pod 的共享上下文包括一组 Linux 名字空间、控制组(CGroup)和可能一些其他的隔离方面, 即用来隔离容器的技术。 在 Pod 的上下文中,每个独立的应用可能会进一步实施隔离。

Pod 类似于共享名字空间并共享文件系统卷的一组容器。

Kubernetes 集群中的 Pod 主要有两种用法:

  • 运行单个容器的 Pod。"每个 Pod 一个容器"模型是最常见的 Kubernetes 用例; 在这种情况下,可以将 Pod 看作单个容器的包装器,并且 Kubernetes 直接管理 Pod,而不是容器。

  • 运行多个协同工作的容器的 Pod。 Pod 可以封装由紧密耦合且需要共享资源的多个并置容器组成的应用。 这些位于同一位置的容器构成一个内聚单元。

将多个并置、同管的容器组织到一个 Pod 中是一种相对高级的使用场景。 只有在一些场景中,容器之间紧密关联时你才应该使用这种模式。

创建一个Pod

# simple-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80
kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml

更新和替换Pod

Kubernetes 并不禁止你直接管理 Pod。对运行中的 Pod 的某些字段执行就地更新操作还是可能的。不过,类似 patchreplace 这类更新操作有一些限制:

  • Pod 的绝大多数元数据都是不可变的。例如,你不可以改变其 namespacenameuid 或者 creationTimestamp 字段。

    • generation 字段是特别的。它将由系统自动设置,使得新 Pod 的 generation 为 1,并且每次更新 Pod 规格中的可变字段时, generation 将增加 1。如果设置了 Alpha 基本特性门控 PodObservedGenerationTracking, 则 Pod 的 status.observedGeneration 将反映报告 Pod 状态时的 Pod 的 metadata.generation

  • 如果 metadata.deletionTimestamp 已经被设置,则不可以向 metadata.finalizers 列表中添加新的条目。

  • Pod 更新不可以改变除 spec.containers[*].imagespec.initContainers[*].imagespec.activeDeadlineSecondsspec.tolerations 之外的字段。 对于 spec.tolerations,你只被允许添加新的条目到其中。

  • 在更新 spec.activeDeadlineSeconds 字段时,以下两种更新操作是被允许的:

    1. 如果该字段尚未设置,可以将其设置为一个正数;

    2. 如果该字段已经设置为一个正数,可以将其设置为一个更小的、非负的整数。

添加临时容器

[临时容器] https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/ephemeral-containers/

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

当由于容器崩溃或容器镜像不包含调试工具而导致 kubectl exec 无用时, 临时容器对于交互式故障排查很有用。

使用临时容器时, 启用进程名字空间共享很有帮助, 可以查看其他容器中的进程。

Pod 安全设置

[为Pod或容器配置安全上下文] https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/security-context/

要对 Pod 和容器设置安全约束,请使用 Pod 规约中的 securityContext 字段。 该字段使你可以精细控制 Pod 或单个容器可以执行的操作。例如:

  • 放弃特定的 Linux 权能(Capability)以避免受到某 CVE 的影响。

  • 强制 Pod 中的所有进程以非 Root 用户或特定用户或组 ID 的身份运行。

  • 设置特定的 seccomp 配置文件。

  • 设置 Windows 安全选项,例如容器是否作为 HostProcess 运行。

# simple-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80
    securityContext: 
      priviledge: true

静态 Pod

静态 Pod(Static Pod) 直接由特定节点上的 kubelet 守护进程管理, 不需要 API 服务器看到它们。 尽管大多数 Pod 都是通过控制面(例如,Deployment) 来管理的,对于静态 Pod 而言,kubelet 直接监控每个 Pod,并在其失效时重启之。

静态 Pod 通常绑定到某个节点上的 kubelet。 其主要用途是运行自托管的控制面。 在自托管场景中,使用 kubelet 来管理各个独立的控制面组件。

kubelet 自动尝试为每个静态 Pod 在 Kubernetes API 服务器上创建一个镜像 Pod。 这意味着在节点上运行的 Pod 在 API 服务器上是可见的,但不可以通过 API 服务器来控制。 有关更多信息,请参阅创建静态 Pod 的指南。