网站开发的流程是网页设计软件免费

17. Init 类型容器有什么特点，主要用途？

特点：

1. 启动顺序：Init 容器在普通容器启动之前运行，必须先完成所有 Init 容器后，Pod 的主容器才会启动。

2. 顺序执行：如果定义了多个 Init 容器，它们会按照定义的顺序依次执行，前一个完成后下一个才会启动。

3. 失败重试：如果 Init 容器执行失败，Kubernetes 会不断重试，直到成功或超出 Pod 的重启策略。

4. 环境隔离：Init 容器的环境和主容器是隔离的，但可以通过共享卷或环境变量传递数据。

5. 一次性运行：Init 容器完成后，不会再运行，也不会影响 Pod 的生命周期。

主要用途：

1. 依赖检查：在主容器启动前检查数据库、缓存等服务是否可用。

2. 环境准备：下载配置文件、初始化数据、创建必要的目录或文件。

3. 权限配置：修改文件权限，确保主容器可以正常访问。

4. 镜像裁剪：一些应用需要大型基础镜像，而 Init 容器可以先运行精简脚本，减少主容器的运行压力。

---

18. Sidecar 类型容器和 Init 容器的区别在哪？

对比项	Init 容器	Sidecar 容器
运行时机	在主容器启动之前运行	与主容器同时运行
运行次数	运行一次后结束	一直运行，直到 Pod 终止
用途	初始化工作，如检查依赖、数据准备	提供额外功能，如日志收集、监控、代理
生命周期	只在启动阶段起作用	在 Pod 运行期间持续工作
失败影响	失败会阻止 Pod 启动	失败可能会影响 Pod 但不会阻止其启动

适用场景：

• Init 容器：适用于 启动前的准备工作，如下载文件、初始化数据、等待外部依赖服务可用等。

• Sidecar 容器：适用于 增强主容器功能，如日志代理（Fluentd）、监控采集（Prometheus Exporter）、代理服务（Envoy）等。

---

19. 什么是静态 Pod？

静态 Pod（Static Pod）是 由 Kubelet 直接管理的 Pod，而不是由 Kubernetes API Server 通过控制器管理的。

特点：

1. 不受 API Server 管理：静态 Pod 不会被存储到 Etcd，也不会被 kubectl get pod 查询到（但可以在 kubectl get pod --all-namespaces 看到）。

2. 由 Kubelet 直接管理：Kubelet 通过本地 manifest 文件来创建和管理静态 Pod，而不是依赖 API Server。

3. 自动重启：如果静态 Pod 进程崩溃，Kubelet 会自动重启它。

4. 自动创建 Mirror Pod：为了让静态 Pod 可以被 kubectl 查询，Kubelet 会在 API Server 上创建一个 Mirror Pod（镜像 Pod），但这个 Pod 只是一个“影子”，无法直接修改。

5. 适用于关键组件：通常用于运行关键组件，如 kube-apiserver、etcd 等。

使用场景：

• Kubernetes Master 组件：如 kube-apiserver、kube-scheduler、kube-controller-manager，在某些部署方式下是以静态 Pod 运行的。

• 边缘计算：在没有完整 Kubernetes 控制平面的情况下，仍然可以使用静态 Pod 运行应用。

• 高可用性：某些关键任务可以使用静态 Pod 运行，以防止 API Server 故障影响服务。

如何创建静态 Pod？
在 Kubelet 配置的 staticPodPath 目录（如 /etc/kubernetes/manifests）下创建 YAML 文件，例如：

# /etc/kubernetes/manifests/nginx-static.yaml
apiVersion: v1
kind: Pod
metadata:name: nginx-staticlabels:app: nginx
spec:containers:- name: nginximage: nginxports:- containerPort: 80

Kubelet 发现该文件后，会自动创建并管理该 Pod。

---

20. 说明 K8s 控制器的作用？

Kubernetes 控制器（Controller）是 Kubernetes 的核心机制之一，它负责自动化管理集群中的资源状态，确保 实际状态（Observed State） 符合 期望状态（Desired State）。

作用：

1. 自动修复：当 Pod、节点或其他资源发生故障时，控制器会自动重新调度或创建新的实例，确保服务正常运行。

2. 扩缩容：如 Deployment 控制器 可以根据需求自动调整 Pod 数量（水平扩缩容 HPA）。

3. 负载均衡：如 Service 控制器 维护 Service 的 Endpoint 以确保流量分发到健康的 Pod。

4. 资源管理：如 ResourceQuota 控制器 限制命名空间的 CPU、内存等资源使用量。

5. 自动回收：如 Job 控制器 运行完任务后自动清理 Pod，避免资源浪费。

6. 状态监测：如 Node 控制器 监测节点状态，如果某个节点长时间无响应，会标记为 NotReady 并迁移 Pod。

常见控制器：

控制器	作用
ReplicationController	确保指定数量的 Pod 始终运行
Deployment	负责管理 Pod 的滚动更新、回滚
StatefulSet	适用于有状态应用，如数据库，保证 Pod 唯一性
DaemonSet	在每个 Node 上运行一个 Pod，适用于日志收集、监控
Job	运行一次性任务，成功后终止
CronJob	定时运行任务，如定期备份
Node Controller	监测节点状态，失联时迁移 Pod
Service Controller	维护 Service 的 Endpoint，实现负载均衡

---