企业官网建设流程全解析

1. Kubernetes Pod 控制器深度解析

作为Kubernetes集群中最基础的调度单元，Pod本身并不具备自我管理能力。这就好比一个刚出生的婴儿需要监护人照料一样，Pod也需要专门的"监护人"来确保它们能够健康运行。在Kubernetes中，这个监护人的角色就是Pod控制器。

1.1 Pod控制器的核心职责

Pod控制器本质上是一种Kubernetes资源对象，它通过持续监控和调节，确保集群中的Pod始终处于用户定义的期望状态。这种设计哲学体现了Kubernetes声明式API的精髓 - 你只需要告诉系统你想要什么，而不需要关心具体如何实现。

具体来说，一个合格的Pod控制器需要具备以下核心能力：

• 副本数量维护：就像严谨的仓库管理员，确保货架上的商品数量永远符合库存记录。无论是节点故障导致Pod意外终止，还是用户主动调整副本数量，控制器都能迅速做出反应。

• 健康状态监控：通过内置的探针机制（Liveness/Readiness Probe），持续检查Pod的运行状况。这相当于给每个Pod配备了24小时值班的私人医生，一旦发现异常立即采取救治措施。

• 滚动更新支持：实现无缝的应用版本升级，就像飞机更换引擎时不需要停飞一样。通过精心设计的替换策略，确保服务在整个更新过程中始终可用。

• 版本回退能力：当新版本出现问题时，可以快速回退到已知良好的历史版本。这为运维人员提供了宝贵的"后悔药"，大大降低了发布风险。

1.2 控制器的工作原理

Pod控制器通过Reconciliation Loop（调和循环）机制工作，这个机制的核心是一个永不停止的监控-比较-调整循环：

1. 监控当前状态：通过Kubernetes API持续获取属于自己管理的所有Pod状态
2. 对比期望状态：将实际状态与用户在YAML中声明的期望状态进行比对
3. 执行调整操作：计算需要创建/删除/修改的Pod数量，调用API执行相应操作
4. 等待下次循环：经过一定间隔（默认2秒）后重新开始整个过程

这个机制看似简单，却非常强大。它使得Kubernetes能够自动应对各种异常情况，包括节点宕机、网络分区、资源竞争等复杂场景。

提示：控制器使用Label Selector来确定哪些Pod归自己管理。这意味着你需要确保Pod模板中的labels与控制器spec.selector.matchLabels完全匹配，否则控制器会"丢失"对Pod的追踪。

2. 六大Pod控制器详解

2.1 ReplicaSet：副本守护者

ReplicaSet是Kubernetes中最基础的Pod控制器，它的设计目标非常简单 - 确保指定数量的Pod副本始终运行。虽然在实际生产中我们很少直接使用ReplicaSet（通常用更高级的Deployment来管理），但理解它的工作原理对掌握Kubernetes至关重要。

核心特性

• 精确副本控制：通过spec.replicas字段定义期望的Pod数量，控制器会持续调整使实际数量匹配期望值
• 滚动扩缩容：支持平滑地增加或减少Pod数量，整个过程完全自动化
• 选择器匹配：使用label selector识别自己管理的Pod，这个机制是所有控制器的基础

典型使用场景

ReplicaSet最适合管理完全无状态的应用实例，比如：

• 简单的REST API服务
• 无状态的Web前端
• 实时数据处理worker

示例配置

apiVersion: apps/v1 kind: ReplicaSet metadata: name: frontend labels: app: guestbook tier: frontend spec: replicas: 3 selector: matchLabels: tier: frontend template: metadata: labels: tier: frontend spec: containers: - name: php-redis image: gcr.io/google_samples/gb-frontend:v3

在这个例子中，我们定义了一个始终保持3个副本运行的frontend应用。如果某个Pod意外终止，ReplicaSet会立即检测到并创建新的Pod来替代它。

2.2 Deployment：无状态应用之王

Deployment是Kubernetes中最常用的控制器，可以看作是ReplicaSet的升级版。它通过管理ReplicaSet来实现更高级的部署策略，为无状态应用提供了完美的管理方案。

核心优势

• 声明式更新：只需修改YAML文件中的镜像版本，Deployment会自动处理所有更新细节
• 滚动更新策略：支持多种更新策略（RollingUpdate/Recreate），确保服务在更新期间不中断
• 版本回滚：内置版本历史记录，可以一键回退到任意历史版本
• 暂停/恢复：支持暂停更新过程，方便进行多步骤部署

更新机制详解

当您修改Deployment的Pod模板（通常是更新容器镜像版本）时，Deployment会创建一个新的ReplicaSet，然后按照以下步骤执行更新：

1. 根据新模板创建Pod（数量由maxSurge参数控制）
2. 等待新Pod变为Ready状态
3. 逐步删除旧Pod（数量由maxUnavailable参数控制）
4. 重复上述过程直到所有Pod都更新完成

这个过程确保了服务容量始终保持在可接受水平，不会因为更新导致服务不可用。

实战示例

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80

关键操作命令：

# 查看更新状态 kubectl rollout status deployment/nginx-deployment # 暂停更新（适用于多步骤部署） kubectl rollout pause deployment/nginx-deployment # 恢复更新 kubectl rollout resume deployment/nginx-deployment # 查看更新历史 kubectl rollout history deployment/nginx-deployment # 回滚到上一个版本 kubectl rollout undo deployment/nginx-deployment # 回滚到特定版本 kubectl rollout undo deployment/nginx-deployment --to-revision=2

2.3 StatefulSet：有状态应用的完美方案

StatefulSet是专为有状态应用设计的控制器，它解决了Deployment无法处理的几个关键问题：稳定的网络标识、有序部署和持久化存储。

核心特性

• 稳定的Pod标识：每个Pod获得一个固定的名称（如web-0, web-1）和对应的DNS记录
• 有序部署策略：Pod按顺序创建（0→N-1）和删除（N-1→0），确保主从架构的正确初始化
• 持久化存储：每个Pod可以拥有独立的PersistentVolumeClaim，数据不会随Pod重建而丢失
• Headless Service：通过无头服务为每个Pod提供唯一的DNS解析记录

典型应用场景

• 数据库集群（MySQL, PostgreSQL, MongoDB）
• 分布式协调服务（Zookeeper, etcd）
• 消息队列（Kafka, RabbitMQ）
• 任何需要持久化数据或固定网络标识的应用

配置示例

apiVersion: v1 kind: Service metadata: name: mysql labels: app: mysql spec: ports: - port: 3306 name: mysql clusterIP: None selector: app: mysql --- apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: serviceName: "mysql" replicas: 3 selector: matchLabels: app: mysql template: metadata: labels: app: mysql spec: initContainers: - name: init-mysql image: mysql:5.7 command: - bash - "-c" - | set -ex # 基于Pod序号生成server-id [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 ordinal=${BASH_REMATCH[1]} echo [mysqld] > /mnt/conf.d/server-id.cnf echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf # 将配置复制到空目录 if [[ $ordinal -eq 0 ]]; then cp /mnt/config-map/master.cnf /mnt/conf.d/ else cp /mnt/config-map/slave.cnf /mnt/conf.d/ fi volumeMounts: - name: conf mountPath: /mnt/conf.d - name: config-map mountPath: /mnt/config-map containers: - name: mysql image: mysql:5.7 env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: mysql-secret key: password ports: - containerPort: 3306 name: mysql volumeMounts: - name: data mountPath: /var/lib/mysql - name: conf mountPath: /etc/mysql/conf.d volumes: - name: config-map configMap: name: mysql-config volumeClaimTemplates: - metadata: name: data spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 10Gi

这个示例展示了一个完整的MySQL集群配置，包含了以下关键点：

1. 使用Headless Service提供DNS解析
2. 通过volumeClaimTemplates为每个Pod创建独立的持久化存储
3. 使用initContainer根据Pod序号配置不同的MySQL角色（master/slave）
4. 从Secret获取敏感信息（root密码）

2.4 DaemonSet：节点级守护者

DaemonSet确保集群中的每个（或指定）节点上都运行一个Pod副本。当有新节点加入集群时，DaemonSet会自动在新节点上创建Pod；当节点从集群移除时，对应的Pod也会被垃圾回收。

典型使用场景

• 集群存储守护进程：如glusterd、ceph
• 日志收集器：如fluentd、logstash
• 节点监控组件：如Prometheus Node Exporter、Datadog agent
• 网络插件：如Calico、Weave Net

配置示例

apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd-elasticsearch namespace: kube-system labels: k8s-app: fluentd-logging spec: selector: matchLabels: name: fluentd-elasticsearch template: metadata: labels: name: fluentd-elasticsearch spec: tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule containers: - name: fluentd-elasticsearch image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2 resources: limits: memory: 200Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers

这个配置展示了典型的日志收集器部署，有几个关键点值得注意：

1. 使用hostPath挂载节点上的日志目录
2. 通过tolerations确保Pod也能在master节点上运行（默认master节点不允许普通Pod运行）
3. 设置了合理的资源限制，避免DaemonSet占用过多节点资源

2.5 Job：一次性任务执行者

Job创建一个或多个Pod，并确保指定数量的Pod成功终止。当Pod成功完成后，Job会跟踪完成状态，不会自动删除Pod（除非手动配置）。

核心特性

• 任务完成保证：确保指定数量的Pod成功运行完成
• 并行控制：通过parallelism参数控制并发数，completions参数控制总完成数
• 失败重试：通过backoffLimit设置重试次数（默认6）
• 定时清理：通过ttlSecondsAfterFinished设置完成后自动删除的延迟时间

使用场景

• 数据库迁移
• 批处理任务
• 科学计算
• 测试任务
• 数据导出/备份

示例配置

apiVersion: batch/v1 kind: Job metadata: name: pi spec: ttlSecondsAfterFinished: 100 backoffLimit: 4 completions: 5 parallelism: 2 template: spec: containers: - name: pi image: perl command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never

这个Job会：

1. 同时运行2个Pod（parallelism）
2. 总共完成5个Pod（completions）
3. 每个Pod计算π的2000位小数
4. 失败时最多重试4次（backoffLimit）
5. 完成后100秒自动删除（ttlSecondsAfterFinished）

2.6 CronJob：定时任务调度器

CronJob基于时间表（schedule）创建Job，类似于Linux系统中的crontab。它对于需要定期执行的任务非常有用。

核心配置

• schedule：Cron格式的时间表，如"*/1 * * * *"表示每分钟执行
• jobTemplate：Job的定义模板，与普通Job配置相同
• concurrencyPolicy：控制并发执行策略（Allow/Forbid/Replace）
• startingDeadlineSeconds：启动截止时间，超过此时限未启动的任务会被视为失败
• successfulJobsHistoryLimit：保留的成功Job历史数量（默认3）
• failedJobsHistoryLimit：保留的失败Job历史数量（默认1）

示例配置

apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec: schedule: "*/1 * * * *" successfulJobsHistoryLimit: 5 failedJobsHistoryLimit: 3 jobTemplate: spec: template: spec: containers: - name: hello image: busybox command: ["/bin/sh", "-c", "date; echo Hello from Kubernetes"] restartPolicy: OnFailure

这个CronJob会：

1. 每分钟执行一次
2. 保留最近5个成功Job和3个失败Job的记录
3. 每次执行时输出当前时间和问候语

3. 配置资源管理实战

3.1 Secret：敏感信息管理

Secret是Kubernetes中存储敏感信息的标准方式，如密码、OAuth令牌、ssh密钥等。与直接写在Pod定义或容器镜像中相比，使用Secret更安全、更灵活。

Secret类型详解

1. Opaque：用户自定义的任意数据，默认类型
2. kubernetes.io/service-account-token：服务账号令牌，用于Pod访问API Server
3. kubernetes.io/dockerconfigjson：用于私有Docker Registry认证
4. kubernetes.io/tls：存储TLS证书和私钥
5. bootstrap.kubernetes.io/token：节点引导令牌

创建与管理

从文件创建：

# 创建用户名和密码文件 echo -n 'admin' > username.txt echo -n 'S!B\*d$zDsb=' > password.txt # 生成Secret kubectl create secret generic db-user-pass \ --from-file=username=username.txt \ --from-file=password=password.txt

YAML定义：

apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4= # echo -n 'admin' | base64 password: UyFCXCpkJHpEc2I=

使用方式

环境变量注入：

apiVersion: v1 kind: Pod metadata: name: secret-env-pod spec: containers: - name: mycontainer image: redis env: - name: SECRET_USERNAME valueFrom: secretKeyRef: name: mysecret key: username - name: SECRET_PASSWORD valueFrom: secretKeyRef: name: mysecret key: password

挂载为文件：

apiVersion: v1 kind: Pod metadata: name: secret-volume-pod spec: containers: - name: mycontainer image: redis volumeMounts: - name: secret-volume mountPath: "/etc/secrets" readOnly: true volumes: - name: secret-volume secret: secretName: mysecret items: - key: username path: my-group/my-username - key: password path: my-group/my-password

3.2 ConfigMap：配置管理利器

ConfigMap用于存储非敏感的配置数据，如配置文件、命令行参数、环境变量等。它允许你将配置与容器镜像解耦，实现更灵活的部署。

创建方式

从文件创建：

# 创建配置文件 echo 'server.port=8080' > application.properties echo 'spring.profiles.active=prod' >> application.properties # 生成ConfigMap kubectl create configmap game-config \ --from-file=application.properties

从目录创建：

kubectl create configmap game-config-2 \ --from-file=configs/

从字面值创建：

kubectl create configmap special-config \ --from-literal=special.how=very \ --from-literal=special.type=good

使用方式

挂载为文件：

apiVersion: v1 kind: Pod metadata: name: configmap-volume-pod spec: containers: - name: test-container image: busybox command: ["/bin/sh", "-c", "cat /etc/config/special.how"] volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: special-config items: - key: special.how path: special.how

环境变量注入：

apiVersion: v1 kind: Pod metadata: name: configmap-env-pod spec: containers: - name: test-container image: busybox command: ["/bin/sh", "-c", "echo $SPECIAL_LEVEL && echo $SPECIAL_TYPE"] env: - name: SPECIAL_LEVEL valueFrom: configMapKeyRef: name: special-config key: special.how - name: SPECIAL_TYPE valueFrom: configMapKeyRef: name: special-config key: special.type

热更新机制

当ConfigMap更新时：

1. 挂载为文件：Kubernetes会定期（约10秒）同步更新，Pod内的文件内容会自动更新
2. 环境变量：不会自动更新，需要重建Pod才能获取新值

可以通过以下命令强制触发Deployment滚动更新：

kubectl patch deployment my-nginx --patch '{"spec": {"template": {"metadata": {"annotations": {"version/config": "20240301"}}}}}'

4. 高级技巧与最佳实践

4.1 Pod控制器选择指南

4.2 配置管理最佳实践

1. 敏感数据必须使用Secret：即使数据已经过加密或哈希处理
2. ConfigMap大小限制：单个ConfigMap不能超过1MiB，大配置应考虑挂载为文件
3. 命名规范：使用有意义的名称，如<应用名>-<环境>-config
4. 版本控制：通过labels或annotations标记配置版本
5. 热更新测试：确保应用能正确处理配置文件的动态更新
6. 默认值处理：应用代码应处理配置项缺失的情况

4.3 常见问题排查

问题1：Pod一直处于Pending状态

可能原因：

• 没有满足节点选择器或亲和性规则
• 资源不足（CPU/内存）
• 持久卷声明无法绑定

排查命令：

kubectl describe pod <pod-name> kubectl get events --sort-by=.metadata.creationTimestamp

问题2：Pod不断重启

可能原因：

• 应用崩溃（检查退出代码）
• 存活探针失败
• 资源限制被触发（OOMKilled）

排查命令：

kubectl logs <pod-name> --previous kubectl describe pod <pod-name>

问题3：Service无法访问Pod

可能原因：

• Pod的labels与Service的selector不匹配
• Pod没有正确声明端口
• 网络策略阻止了流量

排查命令：

kubectl get endpoints <service-name> kubectl describe service <service-name>

问题4：ConfigMap更新未生效

可能原因：

• 使用环境变量方式注入（不支持热更新）
• Pod缓存了旧配置（某些应用需要重启才能加载新配置）
• 更新后时间太短（Kubernetes同步需要时间）

解决方案：

• 对于文件挂载方式，等待约10秒自动同步
• 对于环境变量方式，触发Pod重启（如滚动更新）
• 检查应用自身的配置缓存机制

5. 实战案例：全栈应用部署

让我们通过一个完整的示例，部署一个包含前端、后端和数据库的三层应用，综合运用各种Pod控制器和配置管理技术。

5.1 应用架构

• 前端：Nginx服务，使用Deployment管理，3个副本
• 后端：Node.js API服务，使用Deployment管理，2个副本
• 数据库：MySQL主从集群，使用StatefulSet管理，1主1从
• 日志收集：Fluentd DaemonSet，每个节点运行一个实例
• 定时任务：数据备份CronJob，每天凌晨执行

5.2 数据库部署

# mysql-secret.yaml apiVersion: v1 kind: Secret metadata: name: mysql-secret type: Opaque data: root-password: UEBzc3cwcmQ= # echo -n 'P@ssw0rd' | base64 replication-user: cmVwbA== # echo -n 'repl' | base64 replication-password: cmVwbFBhc3M= # echo -n 'replPass' | base64 # mysql-configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: mysql-config data: master.cnf: | [mysqld] log-bin=mysql-bin server-id=1 binlog_format=ROW slave.cnf: | [mysqld] server-id=2 log-bin=mysql-bin binlog_format=ROW skip-slave-start # mysql-service.yaml apiVersion: v1 kind: Service metadata: name: mysql spec: ports: - name: mysql port: 3306 clusterIP: None selector: app: mysql # mysql-statefulset.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: serviceName: "mysql" replicas: 2 selector: matchLabels: app: mysql template: metadata: labels: app: mysql spec: initContainers: - name: init-mysql image: mysql:5.7 command: - bash - "-c" - | set -ex [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 ordinal=${BASH_REMATCH[1]} echo [mysqld] > /mnt/conf.d/server-id.cnf echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf if [[ $ordinal -eq 0 ]]; then cp /mnt/config-map/master.cnf /mnt/conf.d/ else cp /mnt/config-map/slave.cnf /mnt/conf.d/ fi volumeMounts: - name: conf mountPath: /mnt/conf.d - name: config-map mountPath: /mnt/config-map containers: - name: mysql image: mysql:5.7 env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: mysql-secret key: root-password - name: MYSQL_REPLICATION_USER valueFrom: secretKeyRef: name: mysql-secret key: replication-user - name: MYSQL_REPLICATION_PASSWORD valueFrom: secretKeyRef: name: mysql-secret key: replication-password ports: - containerPort: 3306 name: mysql volumeMounts: - name: data mountPath: /var/lib/mysql - name: conf mountPath: /etc/mysql/conf.d volumes: - name: config-map configMap: name: mysql-config volumeClaimTemplates: - metadata: name: data spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 10Gi

5.3 后端API服务

# api-configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: api-config data: application.properties: | server.port=3000 db.host=mysql db.port=3306 db.name=appdb logging.level.root=INFO # api-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: api-server spec: replicas: 2 selector: matchLabels: app: api-server template: metadata: labels: app: api-server spec: containers: - name: api image: my-registry/api-server:1.2.0 ports: - containerPort: 3000 env: - name: DB_USER valueFrom: secretKeyRef: name: mysql-secret key: replication-user - name: DB_PASSWORD valueFrom: secretKeyRef: name: mysql-secret key: replication-password volumeMounts: - name: config-volume mountPath: /app/config volumes: - name: config-volume configMap: name: api-config items: - key: application.properties path: application.properties # api-service.yaml apiVersion: v1 kind: Service metadata: name: api-service spec: selector: app: api-server ports: - protocol: TCP port: 80 targetPort: 3000

5.4 前端Web服务

# frontend-configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: frontend-config data: nginx.conf: | server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html; } location /api { proxy_pass http://api-service; } } # frontend-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: frontend spec: replicas: 3 selector: matchLabels: app: frontend template: metadata: labels: app: frontend spec: containers: - name: nginx image: nginx:1.19 ports: - containerPort: 80 volumeMounts: - name: config-volume mountPath: /etc/nginx/conf.d - name: html-volume mountPath: /usr/share/nginx/html volumes: - name: config-volume configMap: name: frontend-config items: - key: nginx.conf path: default.conf - name: html-volume emptyDir: {} # frontend-service.yaml apiVersion: v1 kind: Service metadata: name: frontend-service spec: type: LoadBalancer selector: app: frontend ports: - protocol: TCP port: 80 targetPort: 80

5.5 日志收集DaemonSet

apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd namespace: kube-system labels: k8s-app: fluentd-logging spec: selector: matchLabels: name: fluentd template: metadata: labels: name: fluentd spec: tolerations: - key: node-role.kubernetes.io/master effect: NoSchedule containers: - name: fluentd image: fluent/fluentd-kubernetes-daemonset:v1.12.0-debian-elasticsearch7-1.0 env: - name: FLUENT_ELASTICSEARCH_HOST value: "elasticsearch-logging" - name: FLUENT_ELASTICSEARCH_PORT value: "9200" resources: limits: memory: 200Mi requests: cpu: 100m memory: 200Mi volumeMounts: - name: varlog mountPath: /var/log - name: varlibdockercontainers mountPath: /var/lib/docker/containers readOnly: true terminationGracePeriodSeconds: 30 volumes: - name: varlog hostPath: path: /var/log - name: varlibdockercontainers hostPath: path: /var/lib/docker/containers

5.6 数据库备份CronJob

apiVersion: batch/v1beta1 kind: CronJob metadata: name: mysql-backup spec: schedule: "0 3 * * *" successfulJobsHistoryLimit: 3 failedJobsHistoryLimit: 1 jobTemplate: spec: template: spec: containers: - name: mysqldump image: mysql:5.7 command: - /bin/sh - -c - | mysqldump -h mysql-0.mysql -u root -p${MYSQL_ROOT_PASSWORD} --all-databases | gzip > /backup/mysql-$(date +%Y%m%d).sql.gz env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: mysql-secret key: root-password volumeMounts: - name: backup-volume mountPath: /backup restartPolicy: OnFailure volumes: - name: backup-volume persistentVolumeClaim: claimName: mysql-backup-pvc

6. 性能优化与高级特性

6.1 Pod调度优化

节点选择器（nodeSelector）：

spec: template: spec: nodeSelector: disktype: ssd

亲和性与反亲和性（affinity）：

affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - api-server topologyKey: "kubernetes.io/hostname"

资源请求与限制：

resources: requests: cpu: "500m" memory: "512Mi" limits: cpu: "1000m" memory: "1Gi"

6.2 自动伸缩

Horizontal Pod Autoscaler：

apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: api-server-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api-server minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50

6.3 Pod生命周期钩子

postStart和preStop：

lifecycle: postStart: exec: command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"] preStop: exec: command: ["/bin/sh", "-c", "nginx -s quit; while killall -0 nginx; do sleep 1; done"]

6.4 Pod安全策略

SecurityContext：

securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 capabilities: add: ["NET_ADMIN", "SYS_TIME"]

7. 监控与日志

7.1 监控指标

Prometheus监控示例：

apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: api-server-monitor labels: team: backend spec: selector: matchLabels: app: api-server endpoints: - port: web interval: 30s

7.2 日志收集

Fluentd配置示例：

<source> @type tail path /var/log