Kubernetes应用扩展、部署及服务通信全解析

### Kubernetes 应用扩展、部署及通信指南 #### 1. 应用扩展机制 在 Kubernetes 中，应用的扩展是保障其性能和可用性的重要环节。一个典型的扩展事件流程如下： 1. 当一个 Deployment 的三个副本的平均 CPU 使用率超过 70% 时，这表明当前资源可能无法满足应用的负载需求。 2. HPA（Horizontal Pod Autoscaler）控制循环会实时监控 CPU 使用率，一旦检测到这种增长，就会触发后续的扩展机制。 3. HPA 会根据 CPU 利用率计算出新的副本数量，并编辑 Deployment 规格。其目标是使每个节点的 CPU 使用率稳定在 70% 以下，以确保资源的合理利用。 4. Deployment 控制器会根据新的副本数量启动新的副本，从而增加应用的处理能力。 5. 这个过程会不断重复，根据应用的负载情况动态地扩展或缩减 Deployment 的副本数量。 简单来说，HPA 会持续跟踪 CPU 和内存的使用情况，当达到预设的边界值时，就会自动触发扩展事件，以保证应用的稳定运行。 #### 2. DaemonSets 的实现 DaemonSets 是一种特殊的 Pod 控制器，与 ReplicaSets 类似，但有一个显著的区别：DaemonSets 会在集群的每个节点上固定运行一个副本。这意味着在任何时候，集群中的每个节点都会有一个应用的副本处于活动状态。不过，需要注意的是，在没有额外的 Pod 放置控制（如 Taints 或 Node Selectors）的情况下，才会在每个节点上创建一个副本。 DaemonSets 非常适合运行那些需要在节点级别收集指标或提供网络进程的应用。以下是一个典型的 DaemonSet 规格示例： ```yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: log-collector spec: selector: matchLabels: name: log-collector template: metadata: labels: name: log-collector spec: containers: - name: fluentd image: fluentd ``` 可以看到，这个规格与典型的 ReplicaSet 规格非常相似，只是没有指定副本数量。这是因为 DaemonSet 会尝试在集群的每个节点上运行一个 Pod。 如果想指定在特定的节点子集上运行应用，可以使用 node selector。以下是一个示例： ```yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: log-collector spec: selector: matchLabels: name: log-collector template: metadata: labels: name: log-collector spec: nodeSelector: type: bigger-node containers: - name: fluentd image: fluentd ``` 这个 YAML 文件会将 DaemonSet 限制在标签中匹配 `type=bigger-node` 选择器的节点上运行。 #### 3. StatefulSets 的理解 StatefulSets 与 ReplicaSets 和 Deployments 非常相似，但有一个关键的区别，使其更适合有状态的工作负载。StatefulSets 会维护每个 Pod 的顺序和身份，即使 Pod 被重新调度到新的节点上，其身份也不会改变。 例如，在一个包含 3 个副本的 StatefulSet 中，始终会有 Pod 1、Pod 2 和 Pod 3，并且这些 Pod 在 Kubernetes 和存储中会保持其身份，不受任何重新调度的影响。 下面是一个简单的 StatefulSet 配置示例： ```yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: stateful spec: selector: matchLabels: app: stateful-app replicas: 5 template: metadata: labels: app: stateful-app spec: containers: - name: app image: busybox ``` 这个 YAML 文件会创建一个包含 5 个副本的 StatefulSet。 通过 `kubectl get pods` 命令获取所有 Pod 的信息，输出如下： ```plaintext NAME READY STATUS RESTARTS AGE stateful-app-0 1/1 Running 0 55s stateful-app-1 1/1 Running 0 48s stateful-app-2 1/1 Running 0 26s stateful-app-3 1/1 Running 0 18s stateful-app-4 0/1 Pending 0 3s ``` 可以看到，每个 Pod 都有一个数字标识符来表示其身份。这种特性对于有状态的应用（如数据库集群）非常有用，因为在运行数据库集群时，主 Pod 和副本 Pod 的身份非常重要，我们可以利用 StatefulSet 的身份来轻松管理这些关系。 另外，还可以注意到最后一个 Pod 仍在启动中，并且 Pod 的创建时间随着数字身份的增加而增加。这是因为 StatefulSet 的 Pod 是按顺序逐个创建的。 #### 4. Jobs 的使用 Kubernetes 中的 Job 资源主要用于运行可以完成的任务，因此不太适合长时间运行的应用，但对于批处理作业或类似的可以并行执行的任务非常有用。 一个 Job 规格的 YAML 文件示例如下： ```yaml apiVersion: batch/v1 kind: Job metadata: name: runner spec: template: spec: containers: - name: run-job image: node:lts-jessie command: ["node", "job.js"] restartPolicy: Never backoffLimit: 4 ``` 这个 Job 会启动一个 Pod，并运行 `node job.js` 命令，直到任务完成后，Pod 会自动关闭。需要注意的是，这里假设使用的容器镜像中包含 `job.js` 文件来执行作业逻辑，而 `node:lts-jessie` 容器镜像默认是没有这个文件的。这是一个非并行运行的 Job 示例。 如果想创建一个可以并行运行的 Job（即多个副本同时运行该作业），需要在应用代码中实现判断作业是否完成的逻辑。具体步骤如下： 1. 每个 Job 实例需要包含代码，确保它只处理整个批处理任务的一部分，避免重复工作。可以使用一些应用模式来实现，如互斥锁和工作队列。 2. 代码需要检查整个批处理任务的状态，可以通过更新数据库中的值来实现。当 Job 代码检测到整个任务完成时，应该退出。 添加并行性的 Job 示例如下： ```yaml apiVersion: batch/v1 kind: Job metadata: name: runner spec: parallelism: 3 template: spec: containers: - name: run-job image: node:lts-jessie command: ["node", "job.js"] restartPolicy: Never backoffLimit: 4 ``` 在这个示例中，通过 `parallelism` 键指定了 3 个副本同时运行。 还可以指定作业的完成次数，Kubernetes 会跟踪作业的完成情况。例如，以下规格会让作业运行 4 次，每次同时有 2 个迭代运行： ```yaml apiVersion: batch/v1 kind: Job metadata: name: runner spec: parallelism: 2 completions: 4 template: spec: containers: - name: run-job image: node:lts-jessie command: ["node", "job.js"] restartPolicy: Never backoffLimit: 4 ``` #### 5. CronJobs 的配置 CronJobs 是 Kubernetes 中用于定时执行作业的资源，其工作方式与常见编程语言或应用框架中的 CronJob 实现类似，但有一个关键区别：Kubernetes 的 CronJobs 会触发 Kubernetes Jobs，提供了额外的抽象层，可以用于在特定时间（如每晚）触发批处理作业。 CronJobs 使用典型的 cron 表示法进行配置，一个完整的规格示例如下： ```yaml apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec: schedule: "0 1 * * *" jobTemplate: spec: template: spec: containers: ```