k8s运维-pod篇（1）

前言：

依旧是随笔分享，希望对大家有帮助！！！

1. 什么是pod

2. k8s创建pod流程（面试）

Pod 创建流程核心步骤（重点）

阶段一：提交与持久化

1. kubectl 提交：用户通过 kubectl 向 API Server 发送创建 Pod 的请求。

2. API Server 处理：API Server 对请求进行认证、授权和准入控制。

3. 写入 etcd：API Server 将 Pod 的期望状态（spec）作为对象写入 etcd。

4. etcd 确认：etcd 成功持久化数据后，向 API Server 发送确认信号。

5. 响应客户端：API Server 向 kubectl 返回成功响应。此时，Pod 仅被记录，尚未调度。

阶段二：调度与绑定

1. Scheduler 监听：Scheduler 通过 Watch 长连接监听 API Server。

2. API Server 通知：API Server 将新 Pod 事件通知给 Scheduler。

3. 调度决策：Scheduler 执行调度算法（预选和优选），为 Pod 选择最佳节点。

4. 发起绑定：Scheduler 向 API Server 发送请求，更新 Pod 的 nodeName 字段。

5. 写入 etcd：API Server 将此绑定信息写入 etcd。

6. etcd 确认：etcd 向 API Server 确认更新成功。

7. 响应 Scheduler：API Server 告知 Scheduler 绑定操作完成。

阶段三：创建与状态上报

1. Kubelet 监听：目标节点上的 Kubelet 通过 Watch 长连接监听 API Server。

2. API Server 通知：API Server 将 Pod 绑定事件通知给负责该节点的 Kubelet。

3. 创建容器：Kubelet 调用 Container Runtime（通过 CRI）来拉取镜像并创建容器。

4. Runtime 确认：Container Runtime 完成容器创建后通知 Kubelet。

5. 上报状态：Kubelet 向 API Server 上报 Pod 的当前状态（如 status.phase: Running）。

6. 写入 etcd：API Server 将此状态信息写入 etcd。

7. etcd 确认：etcd 向 API Server 确认状态更新持久化完成。

面试话术总结

下述为我总结的面试话术，有需要的可再次加工一下，更加白话文点

第一阶段：提交与持久化
用户通过kubectl提交Pod创建请求，API Server进行校验后，将Pod的期望状态写入etcd并持久化。写入成功后，API Server返回响应，此时Pod已被记录但尚未调度。

第二阶段：调度与绑定
Scheduler监听API Server，发现待调度的Pod后，通过预选和优选算法为Pod分配最佳节点，并回写nodeName到etcd。此阶段完成了Pod与节点的绑定。

第三阶段：创建与状态上报
目标节点的Kubelet监听到绑定事件后，调用容器运行时（如Docker/containerd）拉取镜像并创建容器。容器创建成功后，Kubelet上报Pod运行状态（如Running）到API Server，并再次持久化到etcd。
整个流程通过etcd保证状态一致性，各组件通过Watch机制协同工作，实现了Pod从声明到运行的自动化管理。
开启新对话

3. k8s资源配置清单

常见配置清单参数

皆为常用的配置参数，不需要能够默写，但是得达到一眼能够知道其作用

1. 基础框架 (apiVersion, kind, metadata)

这三个参数是每个清单的"身份证"和"门牌号"，缺一不可。

• apiVersion：

  • 作用：指定使用的Kubernetes API的版本。这决定了可用字段和功能。

  • 举例：apps/v1（用于Deployment, StatefulSet等）， v1（用于Pod, Service, ConfigMap等）， batch/v1（用于Job）。

• kind：

  • 作用：定义要创建的资源类型。它告诉API Server"我要创建一个什么对象"。

  • 举例：Pod, Deployment, Service, Ingress。

• metadata：

  • 作用：提供资源的元数据，即"标识信息"。

  • 关键子字段：

    • name: 资源的名称，在同一个命名空间内必须唯一。

    • namespace: 指定资源所属的命名空间，用于逻辑隔离。

    • labels: 键值对标签，用于标识、选择和关联资源（例如，Service通过label选择Pod）。

    • annotations: 键值对注解，用于存储非识别性元数据，供工具或系统使用（如构建信息、监控配置）。

---

2. 核心配置 (spec)

这是清单的"大脑和心脏"，详细描述了用户所期望的资源状态（Desired State）。不同kind的资源，其spec结构完全不同。

以最常见的 Pod 和 Deployment 为例：

A. Pod的 spec： Pod的spec核心是定义容器组。

• containers (必填): 定义Pod中运行的容器列表。

  • name: 容器的名称。

  • image: 容器镜像地址（如 nginx:1.20）。

  • ports: 容器暴露的端口列表（只是一个声明，不影响实际网络）。

  • env: 注入到容器的环境变量。

  • resources: 至关重要！定义容器的资源请求和限制。

    • requests: 调度依据（例如 cpu: "250m", memory: "64Mi"），Kubelet据此保证容器所需的最小资源。

    • limits: 运行限制（例如 cpu: "500m", memory: "128Mi"），容器资源使用量不能超过此值，防止"饿死"邻居。

  • livenessProbe/readinessProbe/startupProbe: 各种健康探针，用于检查容器的健康状态，是实现高可用的关键。

  • volumeMounts: 将外部存储卷挂载到容器内的特定路径。

• volumes: 定义Pod可用的存储卷来源（如 hostPath, emptyDir, configMap, persistentVolumeClaim）。

B. Deployment的 spec： Deployment通过Pod模板来管理Pod副本，实现部署策略。

• replicas: 指定期望的Pod副本数量，是维持高可用性的基础。

• selector: 定义Deployment如何查找要管理的Pod（通过匹配metadata.labels）。

• template: Pod模板。其内容就是一个完整的Pod spec（见上文），Deployment会根据这个模板来创建新的Pod。

• strategy: 定义Pod更新策略（如 RollingUpdate-滚动更新 或 Recreate-重建），这是实现无损部署和版本回滚的关键。

---

3. 状态观察 (status)

这个部分由Kubernetes系统自动生成和维护，它描述了资源的"当前状态（Current State）"。我们通常不手动配置它。

• 作用：用户和控制器通过比较 spec (期望状态) 和 status (当前状态) 的差异，来驱动Kubernetes进行调谐（Reconcile），最终使当前状态符合期望状态。

• 举例：status中会包含Pod的phase（阶段，如Running）、conditions（条件，如Ready）、hostIP、podIP等信息。

4. Pod 生命周期中的容器钩子（Hooks）和探针（Probes）

执行流程图：

Init Container (初始化容器)

Init Container (初始化容器)

• 是什么：是一种特殊容器，在主容器（Main Container） 启动之前运行。

• 作用：完成主容器运行前的预备工作，如等待其他服务就绪、安装软件、从远端拉取配置文件、迁移数据库等。

• 特点：它们必须运行成功完成（run to completion） 后，下一个 Init Container 或主容器才能启动。如果失败，Pod 会根据 restartPolicy 策略重启它们。

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod

spec:
  initContainers:
    - name: init-conatainer
      image: busybox:1.28
      command: ['sh', '-c', 'echo init container is ok! && sleep 30']

  containers:
    - name: my-container
      image: busybox:1.28
      command: ['sh', '-c', 'echo The app is running! && sleep 3600']

#使用如下命令应该可以从pod日志当中找到上述输出的语句
kubectl logs -f my-container-xxx  

postStart (启动后钩子)和preStop (停止前钩子)

参考文档：https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/

postStart (启动后钩子)

• 是什么：容器 lifecycle 钩子之一。在容器被创建之后立即执行。

• 作用：用于在容器启动后执行一些自定义命令或脚本，例如向外部系统发送通知、初始化一些特定数据。

• 重要注意：它不保证在容器入口点（ENTRYPOINT）之前执行，它是异步执行的。

preStop (停止前钩子)

• 是什么：容器 lifecycle 钩子之一。在容器被终止之前执行。

• 作用：这是实现优雅停止（Graceful Shutdown） 的关键。它允许容器在收到终止信号（SIGTERM）之前，执行一些清理操作，例如：

  • 通知上游服务自己正在下线。

  • 完成正在处理的请求。

  • 安全地保存状态或断开数据库连接。

  • 睡眠几秒以等待流量排空。

• 执行后：执行完 preStop 钩子后，kubelet 会向容器的主进程发送 SIGTERM 信号。

案例：

作用：
拉取nginx镜像生成容器，并映射宿主机上/data到容器当中
容器启动时，向/usr/share/nginx/html/start.html目录下插入postStart ok
容器销毁时，查询宿主机上/data目录下stop.log文件内容是否为nginx is stop!!!

apiVersion: v1
kind: Pod
metadata: 
  name: nginx
spec:
  volumes:
    - name: host-volumes
      hostPath:
        path: /data
        type: DirectoryOrCreate
  containers:
    - name: nginx
      image: nginx

      volumeMounts:
        - mountPath: /data/
          name: host-volumes
      ports:
        - containerPort: 80
      lifecycle:
        postStart:
          exec:
            command: ["/bin/sh", "-c", "echo  postStart ok > /usr/share/nginx/html/start.html"]
        preStop:
          exec:
            command: ["/bin/sh","-c","echo nginx is stop!!! > /data/stop.log;nginx -s stop"]

存活性探针

1. Exec (执行命令)

• 机制：在容器内部执行指定的命令。如果命令的退出状态码 (exit code) 为 0，则认为探测成功；非零则视为失败。

• 适用场景：适用于可以通过执行一个检查命令来判断应用内部状态的场景。例如，检查一个特定的"健康状态文件"是否存在，或者使用应用专用的CLI工具来检查状态。

当存活探针失败后，最终结果是：Kubelet 会杀死（Kill）这个失败的容器，并根据 Pod 的 restartPolicy 策略来重启（Restart）一个新的容器。

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
spec:
  containers:
    - name: liveness
      image: nginx
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 80
      livenessProbe:
        exec:
          command:
            - cat
            - /usr/share/nginx/html/index.html
        initialDelaySeconds: 5
        periodSeconds: 5

initialDelaySeconds:第一次初始化后多少秒探测
periodSeconds：后续间隔多少秒探测

2. httpget

• 机制：向容器内指定的 IP、端口和路径发起 HTTP GET 请求。如果响应的状态码大于等于 200 且小于 400，则认为探测成功；其他状态码则视为失败。

• 工作原理：上例中，kubelet 会每隔 3 秒向容器的 8080 端口的 /healthz 路径发送 HTTP GET 请求，并附带一个自定义头。如果该端点返回 200 OK，则应用是健康的。

• 适用场景：这是最常用的方式，适用于任何提供 HTTP 服务的应用（如 Web 服务、API 服务、微服务）。应用需要实现一个专用的健康检查端点（如 /healthz, /status）。

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
      - name: Custom-Header
        value: AwesomeValue
  initialDelaySeconds: 3
  periodSeconds: 3

3. tcpsocket

• 机制：尝试与容器指定的端口建立 TCP 连接。如果连接建立成功，则认为探测成功；如果连接失败（如超时或拒绝连接），则视为失败。

• 工作原理：上例中，kubelet 会每隔 20 秒尝试与容器的 22 端口（SSH 端口）建立 TCP 连接。只要端口是打开的，能完成三次握手，就算成功，即使端口后面没有任何业务逻辑。

• 适用场景：适用于不提供 HTTP 服务，但开放了特定端口的应用。例如，数据库（Redis, MySQL）、SMTP、FTP 服务等。它只检查端口是否可连接，不检查服务内部状态。

livenessProbe:
  tcpSocket:
    port: 22
  initialDelaySeconds: 15
  periodSeconds: 20