k8s支持那些容器？containerd如何实现容器功能？

• 支持的容器运行时:

  • Docker (早期，现已废弃)

  • containerd (目前最主流的)

  • CRI-O (轻量级，为K8s而生)

• containerd 实现容器功能:

  1. 容器镜像管理: 从仓库拉取镜像，并存储和管理。

  2. 容器生命周期管理: 通过 containerd-shim 和 runc 来创建、启动、停止、删除容器。

  3. 使用 runc: containerd 最终会调用 runc（一个符合OCI标准的轻量级命令行工具）来真正创建容器进程。runc 负责利用 Linux 内核的 Namespace 和 Cgroups 功能。

  4. Namespace 实现隔离: 为每个容器创建独立的进程、网络、文件系统等视图。

  5. Cgroups 实现资源限制: 限制容器可使用的CPU、内存等资源。

有哪些常见namespace？

• PID: 进程隔离。

• Network: 网络栈隔离（网络设备、IP地址、端口等）。

• Mount: 文件系统挂载点隔离。

• UTS: 主机名和域名隔离。

• IPC: 进程间通信资源隔离。

• User: 用户和用户组ID隔离。

• Cgroup: Cgroup根目录隔离 (Linux 4.6+)。

K8s去做应用部署的过程中，你是怎么去保证它在部署过程中的一些有效稳定性的？

这是关于部署策略和运维实践的问题。

1. 使用健康检查: 配置有效的 liveness 和 readiness 探针。

2. 采用合适的部署策略:

   • RollingUpdate: 逐步用新Pod替换旧Pod，保证服务始终有可用实例。

   • Blue-Green: 部署两套完全独立的环境，通过切换流量实现零停机部署。

   • Canary: 将一小部分流量引入新版本，验证通过后再全量发布。

3. 资源限制与请求: 为Pod设置 resources.requests 和 resources.limits，防止单个应用耗尽节点资源。

4. PodDisruptionBudget: 在节点维护时，保证至少有多少个Pod可用。

5. 监控与告警: 集成Prometheus、Grafana，实时监控应用和集群状态，出现问题及时告警。

6. 日志收集: 使用EFK/ELK Stack，便于问题追溯。

开发健康检查需要注意哪些？

• 检查逻辑要轻量: 检查核心依赖和关键逻辑，避免复杂计算，防止因健康检查本身拖垮服务。

• 区分就绪和存活:

  • 就绪探针: 检查应用是否准备好接收流量（如：数据库连接是否建立，缓存是否加载完）。失败时，从Service的Endpoint中移除Pod。

  • 存活探针: 检查应用是否活着。失败时，Kubelet会重启容器。

• 设置合理的超时和周期:

  • initialDelaySeconds: 给容器足够的启动时间。

  • periodSeconds, timeoutSeconds, failureThreshold: 组合调整，避免因网络抖动等临时问题导致误判。

• 检查点要具有代表性: 例如，一个Web应用的健康检查端点应该检查数据库连接、缓存连接等。

健康检查放在哪个文件配置，包含哪些资源？

在K8s的 Deployment YAML文件中配置，属于Pod模板的一部分。

• 资源: spec.template.spec.containers 下的 livenessProbe 和 readinessProbe。

• 配置示例:

  yaml

  apiVersion: apps/v1
  kind: Deployment
  spec:
    template:
      spec:
        containers:
        - name: my-app
          image: my-app:v1
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

怎么保证Pod服务不中断？

这是一个高可用问题的核心。

1. 多副本: 通过Deployment部署多个Pod副本。

2. 反亲和性: 设置 podAntiAffinity，让Pod分散到不同的Node上，避免单点故障。

3. 就绪探针: 确保只有完全准备好的Pod才会接收流量。

4. Service负载均衡: Service自动为健康的Pod提供负载均衡。

5. 优雅终止: 在Pod终止前，给应用一个 terminationGracePeriodSeconds 时间来处理完现有请求。

6. 使用PreStop钩子: 在容器终止前执行命令，如从注册中心注销、等待一段时间等。