前提介绍

Kubernetes，亦被称为 K8s，是业界公认的容器编排巨擘，以其卓越的能力简化了容器化应用的部署、扩展和管理流程。通过其强大的功能，Kubernetes 不仅提升了应用的可靠性和可伸缩性，还优化了资源利用率，为开发者和运维人员提供了更加高效、灵活的容器运行环境。

在传统的应用部署模式中，不同环境间的基础设施与配置差异构成了巨大的挑战，使得跨环境部署变得困难重重。然而，Kubernetes 的出现彻底改变了这一局面。它通过构建一个统一的容器编排平台，巧妙地将底层基础设施的复杂性进行了抽象，让开发人员能够摆脱繁琐的环境配置问题。在 Kubernetes 的助力下，应用程序可以在不同环境中实现一致且高效的部署与管理，这不仅极大地提升了应用的可移植性，更为未来的扩展性奠定了坚实的基础。

文章主旨

本篇文章是学习开发使用 k8s 的必备工具，提供了对无缝部署管理所需的基本命令的快速访问。让我们将其视为快节奏 Kubernetes 环境中的必备指南，以提高生产力，减少错误，并确保在复杂任务中的高效导航。不仅包含了 Kubernetes 中最常用的命令，还提供了针对特定任务的实用提示和最佳实践。无论您是经验丰富的 Kubernetes 管理员还是初学者，这份速查表都将成为您日常工作中的宝贵资源。

通过本系列文章，您可以快速了解如何创建和管理部署（Deployments）、服务（Services）、持久存储（Persistent Storage）以及其他 Kubernetes 资源。

基础认识

下面是关于 Kubernetes 所需的关键组件的介绍：

基础架构

Kubernetes 采用高效的客户端-服务器架构，其核心由控制平面（Control Plane）和一组专门用于运行容器的节点（Nodes）构成。这种架构确保了系统的可扩展性、灵活性和可靠性，使得 Kubernetes 成为容器编排领域的佼佼者。

Kubernetes 客户端-服务器架构

Kubernetes 采用客户端-服务器架构，由控制平面（Control Plane）和一组运行容器的节点（Nodes）组成。

控制平面（Control Plane）

控制平面是 Kubernetes 集群的大脑，负责做出全局决策，如调度工作负载、维护集群的状态等。控制平面主要由以下几个组件组成：

1. API 服务器（API Server）：

2. 提供 RESTful API，供用户和其他组件与 Kubernetes 集群交互。

3. 负责认证、授权和 API 访问控制。

4. etcd：

5. 一个高度可用的键值存储系统，用于持久保存集群的状态。

6. 控制平面组件使用 etcd 存储集群数据，如 Pod、Service、Deployment 等的配置和状态信息。

7. 控制器管理器（Controller Manager）：

8. 负责运行各种控制器，这些控制器是后台进程，用于处理集群中资源对象（如 Pods、ReplicationControllers、Services 等）的创建、更新、删除和复制等操作。

9. 例如，复制控制器（ReplicationController）确保指定数量的 Pod 副本始终在运行。

10. 调度器（Scheduler）：

11. 负责决定新 Pod 应该被调度到哪个 Node 上运行。

12. 考虑各种因素，如资源可用性、硬件限制、Pod 的约束和亲和性等。

节点（Nodes）

节点是 Kubernetes 集群的工作负载运行场所，每个节点都运行着以下组件：

1. Kubelet：

2. 负责管理 Pod 和容器，确保容器按照期望的状态运行。

3. 与 Master 节点上的 API 服务器通信，接收并执行指令。

4. Kube-proxy：

5. 负责实现 Kubernetes Service 的网络代理功能。

6. 它能够处理网络流量，实现 Service 的负载均衡和网络访问。

7. 容器运行时（Container Runtime）：

8. 如 Docker、containerd 或 CRI-O 等。

9. 负责运行和管理容器。

客户端工具

此外，Kubernetes 还提供了一系列客户端工具，如 kubectl，它是 Kubernetes 的命令行界面（CLI），用于与集群进行交互，执行如部署应用、管理资源等操作。

通过这种架构，Kubernetes 能够在控制平面和节点之间实现高效的协调，为用户提供易于使用和灵活强大的容器编排功能。

基础命令

在掌握了 Kubernetes 的基本术语和架构之后，接下来我们需要熟悉一些关键的基础命令，以便更好地管理 Kubernetes 集群。这些命令不仅能够帮助我们深入了解集群的状态和配置，还能快速概览可用资源及其版本。通过运用这些命令，我们能够更加高效地管理 Kubernetes 集群，确保系统的稳定运行和资源的合理利用。

具体来说，这些命令提供了集群的整体信息，包括版本、配置、API 资源等关键要素。通过执行这些命令，我们可以快速了解集群的当前状态，以及哪些资源是可用的。这对于日常维护和故障排除非常有帮助，能够让我们及时发现问题并采取相应的措施。

Pod 和容器

Pod 是 Kubernetes 中最小的可部署单元，代表着集群中运行进程的单一实例，作为基本的构建模块，Pod 可以容纳一个或多个容器，这些容器共享相同的网络命名空间，从而允许它们通过 localhost 进行无缝通信。

容器是一种轻量级、独立且可执行的软件包，它封装了运行软件所需的所有依赖，包括代码、运行时环境、库和系统工具。通过容器，应用程序能够获得一个稳定且隔离的运行环境，确保其在不同场景下都能保持一致的表现。

创建、管理 pod 和排除故障的常用命令

Pod 和容器的设计分析

在 Kubernetes 环境中，高效的容器化策略对于应用程序的顺畅部署和管理至关重要。以下是优化容器化应用程序的几个核心设计：

• 遵循单一职责原则，确保每个容器都具备明确且特定的功能。这种模块化设计不仅简化了维护流程，还增强了应用程序的稳健性。

• 尽可能减小容器镜像的大小，通过去除不必要的层级和依赖关系来实现。较小的镜像能够加快部署速度，同时减少资源消耗，从而提升整体性能。

• 利用环境变量来配置应用程序，以提高其灵活性和可调整性。这种方法允许在不修改容器镜像的情况下轻松调整设置，从而适应不同的环境和需求。

• 在应用程序中实施健康检查机制，使 Kubernetes 能够准确评估其健康状态。这有助于实现自动修复和确保可靠的应用程序性能，减少潜在的运行时问题。

• 为容器设置合理的 CPU 和内存等资源限制，以防止资源过度消耗。通过限制容器的资源使用，可以确保公平的资源分配，避免个别行为异常的容器对整个集群产生不良影响。

Pod 指令大全快速查找

创建 pod 容器的 Yaml 格式

在 Kubernetes 中，采用多容器 Pod 的策略可以显著增强同一 Pod 内部各容器间的协作与资源共享能力。以下是几种不同的多容器模式的代码示例，以展示其实际应用。

介绍之前，先给大家总结一个 Pod 的结构的 yaml 基础结构图

  apiVersion：API版本，指定了Pod的配置所遵循的Kubernetes API版本  kind：资源类型，指定为"Pod"  metadata：元数据，包含了关于Pod的信息    - name：Pod的名称    - labels：标签，用于标识和选择Pod  spec：规格，定义了Pod的规格和配置    - containers：容器列表，包含了Pod中的一个或多个容器      - name：容器名称      - image：容器所使用的镜像      - ports：容器的端口配置        - containerPort：容器内部的端口号        - protocol：协议类型（如TCP、UDP）    - volumes：卷列表，用于挂载到Pod中的容器中      - name：卷名称      - emptyDir：空目录，用于将容器的临时数据存储在内存中

这是一个基本的 Kubernetes（k8s）Pod 的基本结构，你可以根据自己的需要进一步添加和修改配置。

Sidecar 容器模式

Sidecar 容器模式是一种创新的容器编排策略，它允许在主应用程序容器的旁边部署一个或多个辅助容器，用以增强或扩展主容器的功能。

apiVersion: v1  kind: Pod  metadata:    name: sidercar-pod  spec:    containers:    - name: main-server      image: main-server:1.0    ports:      - containerPort: 8081      - name: sidecar-collector      image: sidecar-collector:1.0    ports:      - containerPort: 8082        

这种模式的独特之处在于其能够无缝集成日志收集、监控等额外功能，使应用程序的运行更加高效和可靠。通过 Sidecar 容器，开发人员能够更灵活地管理和维护应用程序，提升整个系统的可扩展性和可维护性。

Adapter 容器模式

Adapter 容器模式是一种强大的策略，它专门设计用来在应用程序与特定的后端服务或资源（例如数据库）之间建立适配层。这种模式的目的是将后端通信的复杂性封装在 Adapter 容器中，从而保持主应用程序容器的清晰和简洁。通过 Adapter 容器，开发人员能够将应用程序与后端服务的解耦，提高代码的模块化和可维护性，同时确保应用程序的稳定运行和可扩展性。

apiVersion: v1  kind: Pod  metadata:    name: adapter-pod  spec:    containers:    - name: main-server      image: main-server:1.0    ports:      - containerPort: 8081          - name: pgdata-adapter      image: pgdata:1.0      ports:      - containerPort: 8082        

适配器容器在数据流向主应用程序之前，会对其进行必要的转换或调整，以确保数据的兼容性和有效性。这一过程旨在消除不同系统间的差异，提供一个统一、无缝的集成点，使应用程序能够无缝地利用后端资源，实现更顺畅、高效的数据流通。

Ambassador 容器模式

在这种架构中，Ambassador 容器扮演着至关重要的中介角色，它代表主应用程序处理所有通信和网络相关任务，确保数据的安全、高效和准确传输。

apiVersion: v1  kind: Pod  metadata:    name: Ambassador-pod  spec:    containers:    - name: main-server      image: main-server:1.0    ports:      - containerPort: 8081          - name: Ambassador-adapter      image: Ambassador:1.0      ports:      - containerPort: 8082        

Ambassador 容器模式类似于 Adapter，但更侧重于提供与外部世界（如 API 网关）的通信。使用不同类型的容器，以实现更灵活和强大的应用程序部署和管理。通过结合这些模式，您可以根据应用程序的需求和架构来定制和优化 Pod 的设计。

最后还有一种 init 模式，配置方式类似，在这里我就不一一列举了，Init 容器在应用程序容器启动之前运行，常用于执行一些前置条件，如配置环境、下载依赖或等待外部资源就绪。有兴趣的小伙伴，可以好好研究一下。

Deployments 和 ReplicaSets

Deployments 与 ReplicaSets 在 Kubernetes 集群中扮演着至关重要的角色，共同管理应用程序的部署、扩展和更新生命周期，部署和副本集共同协作，为 Kubernetes 集群中的应用程序提供了强大而灵活的管理和扩展能力，确保了应用程序的高可用性和稳定性。

• 部署（Deployment）是 Kubernetes 中的一个核心概念，它提供了一种声明式的方式来定义、更新和管理应用程序的生命周期。通过部署，开发人员可以轻松地指定他们希望运行的应用程序版本和配置，而 Kubernetes 则会负责实际的部署和更新过程。

• 副本集（ReplicaSet）与部署紧密关联，它充当了一个控制器的角色，确保指定数量的相同 Pod 副本始终在运行状态。这意味着，无论发生何种故障或变化，副本集都会确保有足够的 Pod 副本可用，以满足应用程序的需求和性能要求。

生命周期

Kubernetes 中的部署管理 pod 的部署和扩展，提供了一种声明式方法来定义所需的状态。生命周期包括几个关键阶段：

• 部署创建：首先，您需要创建一个部署，其中明确指定所需的副本数量以及 pod 的模板规格。这是部署过程的基础。

• 副本集生成：一旦部署被创建，Kubernetes 将自动生成一个与之关联的 ReplicaSet。这个 ReplicaSet 的职责是确保始终有指定数量的 pod 副本正在运行。

• Pod 创建与扩展：根据在部署中定义的模板，ReplicaSet 会负责创建单个 pod。当您需要扩展应用程序时，只需调整所需的副本数量即可。部署会实时监控并确保始终维持正确的 pod 数量。

• 滚动更新机制：当您需要更新应用程序时，部署系统将采用一种称为滚动更新的策略。这意味着，它会使用更新后的配置来创建新的 ReplicaSet，同时逐步缩减旧的 ReplicaSet。这一过程确保了更新过程中的平滑过渡，避免了服务中断。

• 终止与完成：最终，旧的 ReplicaSet 会被完全缩减至零，标志着更新过程的结束。此时，整个系统已完全过渡到使用更新后的配置和 pod。

Deployments 指令大全快速查找

部署和管理滚动更新扩展应用程序的方案

扩展部署

• 扩展至指定数量的副本： kubectl scale deployment <deployment_name> --replicas=<num>
  

• 根据 CPU 使用率自动扩展： kubectl autoscale deployment <deployment_name> --cpu-percent=<percentage> --min=<min_replicas> --max=<max_replicas
  

管理滚动更新

• 使用新镜像更新部署： kubectl set image deployment/<deployment_name> <container_name>=<new_image>
  

• 监控滚动更新进度： kubectl rollout status deployment/<deployment_name>
  

• 回滚到先前版本：kubectl rollout undo deployment/<deployment_name>
  

• 暂停和恢复滚动更新：kubectl rollout pause deployment/<deployment_name> 和 kubectl rollout resume deployment/<deployment_name>
  

• 自定义更新策略：kubectl apply -f customer-deployment-strategy.yaml
  

这些命令为快速扩展部署、满足需求以及有效管理滚动更新提供了便捷的参考。无论您需要调整副本数量，还是希望运用不同的策略来协调更新，这份详尽的指南都将助您一臂之力，极大地简化 Kubernetes 环境中的部署流程。

创建和更新 ReplicaSet 的案例

创建 ReplicaSet

配置文件定义了一个名为 demo-replicaset 的 ReplicaSet，其主要职责是确保运行三个 pod 副本。每个 pod 都基于一个模板创建，该模板包含了一个名为 demo-container 的容器，该容器使用 demo-image:latest 镜像。

apiVersion: apps/v1kind: ReplicaSetmetadata:  name: demo-replicasetspec:  replicas: 3  selector:    matchLabels:      app: demo  template:    metadata:      labels:        app: demo    spec:      containers:      - name: demo-container        image: demo-image:latest

这样的配置有助于确保应用程序的高可用性和可扩展性，当某个 pod 出现故障或被删除时，ReplicaSet 会自动启动新的 pod 以替代它。

更新 ReplicaSet

apiVersion: apps/v1kind: ReplicaSetmetadata:  name: demo-replicasetspec:  replicas: 5  # Update the number of replicas  selector:    matchLabels:      app: demo  template:    metadata:      labels:        app: demo    spec:      containers:      - name: demo-container        image: updated-demo-image:latest  # Update the container image

YAML 配置现在针对名为 'demo-replicaset' 的现有 ReplicaSet 进行了更新。新的配置将所需的副本数量调整至 5 个，同时，Pod 模板也经过了更新，现在使用 'updated-demo-image:latest' 作为容器镜像。这些更改将确保 ReplicaSet 能够以更高的可用性和灵活性运行，以满足不断变化的业务需求。"

下篇预告

在即将发表的文章中，我们将进一步聚焦于服务与网络（Services and Networking）相关的核心组件，进行深入的介绍、分析和阐释。通过这篇文章，读者将能够更全面地了解这些组件的功能、特点以及它们在整体架构中的重要性。我们期待通过分享专业知识和经验，为读者提供更深入、更全面的了解和掌握这些关键组件的机会。