[云] Running our first containers on Kubernetes

Running our first containers on Kubernetes

在[云] Getting Started with Kubernetes - Environment setup 环境配置-CSDN博客的基础上：

在深入实际操作之前，让我们先澄清一些关于 Kubernetes 如何管理容器的关键概念，特别是通过 Pod 的方式：

Kubernetes 和通过 Pod 管理的容器

在 Kubernetes 中，容器并不是孤立运行的，而是在 Pod 中运行。Pod 是 Kubernetes 创建和管理的最小可部署单元。以下是关于 Pod 的一些基本知识：

• 容器组：一个 Pod 可以包含一个或多个紧密耦合的容器。同一个 Pod 中的容器共享相同的网络 IP、端口空间、存储和其他资源。
• 共享资源：同一个 Pod 中的容器可以通过本地挂载的卷共享文件。它们通过 localhost 进行通信，并共享相同的资源限制（RAM、CPU）。
• 节点部署：Pod 中的所有容器都被调度到同一个节点上运行（物理或虚拟机）。

使用 Ping 命令运行简单的 Pod

接下来，让我们演示如何在 Kubernetes 中运行一个执行简单操作（如 ping 命令）的 Pod。然后，我们将扩展这个 Pod 来创建额外的副本。这将展示在 Kubernetes 环境中创建、执行和扩展 Pod 的基本过程。

通俗解释：

当我们运行这个命令后，Kubernetes 将在集群中创建一个名为 pingpong 的部署。这个部署里的容器将会基于 Alpine Linux 镜像启动，并且执行 ping 1.1.1.1 命令，帮助我们检测到 Kubernetes 集群到 Cloudflare DNS 服务器的网络连接和响应时间。这是一个检查和确认我们的集群能够访问互联网的简单方法。

1. 定义一个 Pod： 您需要创建一个定义 Pod 及其中容器的 YAML 文件。以下是一个运行执行 ping 命令的单容器 Pod 的基本 YAML 文件示例：

2. 启动一个简单的 Pod

   在 Kubernetes 中，我们可以使用 kubectl create deployment 命令来快速启动一个 Pod。这个命令至少需要指定一个名称和你想使用的镜像。

   比如，我们要 ping 云服务商 Cloudflare 的公共 DNS 解析器地址 1.1.1.1，可以这样操作：

3. $ kubectl create deployment pingpong --image=alpine -- ping 1.1.1.1
   

   解释如下：

4. 命令行操作：在 Kubernetes 中启动 Pod 的一个常用命令是 kubectl create deployment。通过这个命令，我们可以创建一个名为 pingpong 的部署。
5. 部署名称：在这个示例中，我们将部署命名为 pingpong，这只是一个标识，你可以根据需要命名为任何合适的名称。
6. 使用镜像：--image=alpine 指定了 Pod 中容器使用的基础镜像，这里使用的是 Alpine Linux，一个轻量级的 Linux 发行版。
7. 执行命令：部署中的容器启动后将执行 ping 1.1.1.1 命令。这里 ping 是用于检测网络连接和响应速度的命令，而 1.1.1.1 是 Cloudflare 提供的公共 DNS 服务的 IP 地址。
8. （这里的“镜像”是指一个容器镜像，它是一个轻量级、可执行的独立软件包，包含运行一个应用所需的所有代码、运行时环境、库和配置文件。

   在这种情况下，Alpine Linux 镜像被用作容器的基础环境。Alpine Linux 是一个面向安全和资源效率的轻量级 Linux 发行版，非常适合在容器环境中使用，因为它的体积小，启动速度快。

   所以，当这个部署命令执行后，Kubernetes 会在集群的一个或多个节点上启动一个新的容器实例，这些容器实例都运行着 Alpine Linux 系统，并在其中执行我们指定的 ping 1.1.1.1 命令。）   

Kubernetes 资源创建方式

在 Kubernetes 中，有多种方式可以创建和管理资源，每种方式各有特点和适用场景。这里介绍两种主要的命令：

1. 使用 kubectl create 命令：

   • 直接创建资源：可以通过 kubectl create <resource> 命令直接创建资源，这种方式比较直接明了。
   • 局限性：
     • 不能创建 CronJob：使用 kubectl create 命令时，某些特定类型的资源如 CronJob 无法直接创建。
     • 不能传递命令行参数给部署：当使用 kubectl create 创建部署（deployments）时，不能直接在命令行中传递参数，这限制了其灵活性。

2. 使用 YAML 文件和 kubectl create -f 或 kubectl apply -f 命令：

   • 完整功能：通过编写 YAML 配置文件并使用 kubectl create -f foo.yaml 或 kubectl apply -f foo.yaml 命令，你可以访问 Kubernetes 的所有功能。
   • 要求编写 YAML：这种方式需要预先编写 YAML 文件。YAML 文件是一种常用于配置数据输入和交互式应用程序的数据序列化格式，通过详细描述资源的各个方面，可以精确控制资源的创建和配置。

通俗解释：

• kubectl create 命令：这是一个比较基础的命令，适合快速创建简单的资源，比如一个基础的 Pod 或 Service。但如果你需要创建更复杂的资源或需要更灵活的配置，这个命令可能就不够用了。
• YAML 文件和 kubectl apply 命令：这种方法更加强大和灵活，允许你详细定义资源的配置。虽然需要先写好配置文件，但它使得资源管理更加一致和可重复，特别是在自动化部署和大规模管理时非常有效。

了解 kubectl create deployment 命令的背后过程  

当我们使用 kubectl create deployment 命令在 Kubernetes 中创建一个部署时，会自动创建多种资源类型。为了查看这些资源，我们可以使用以下命令：

$ kubectl get all

执行这个命令后，你应该能看到以下几种资源：

1. 部署（Deployment）：

   • deployment.apps/pingpong：这是我们刚刚创建的部署资源，它描述了如何在 Kubernetes 集群中运行和管理应用程序的实例。

2. 副本集（ReplicaSet）：

   • replicaset.apps/pingpong-xxxxxxxxxx：部署自动创建的副本集，用于确保指定数量的 Pod 副本始终运行。副本集是通过部署的规范来管理的，部署会自动处理副本集的创建和更新。

3. Pod：

   • pod/pingpong-xxxxxxxxxx-yyyyy：由副本集创建的具体 Pod，每个 Pod 是运行容器的实例。Pod 名称中的 xxxxxxxxxx-yyyyy 是自动生成的，确保每个 Pod 的唯一性。

• A deployment is a high-level construct

• allows scaling, rolling updates, rollbacks

• multiple deployments can be used together to implement a canary deployment

• delegates pods management to replica sets

• A replica set is a low-level construct

• makes sure that a given number of identical pods are running

• allows scaling

• rarely used directly

部署（Deployment）

• 高级构造: 在 Kubernetes 中，部署被视为一种高级 API 对象，它通过自动管理 Pod 和副本集的生命周期来管理应用程序。
• 扩展、滚动更新、回滚: 部署允许你增加或减少 Pod 实例的数量，执行滚动更新以在不停机的情况下更新运行在这些 Pod 上的软件，并且在出现问题时回滚到之前的版本。
• 金丝雀部署: 部署还可以配置为一起工作，用于实施金丝雀部署等高级部署策略。在金丝雀部署中，新版本的应用程序逐渐向一小部分用户推出，然后再向整个基础设施推出，这有助于在不影响所有用户的情况下发现问题。

副本集（Replica Set）

• 低级构造: 副本集是一个较低级别的构造，确保始终运行指定数量的相同 Pod。
• 管理 Pod: 它负责维护正确数量的 Pod，确保总是有指定数量的相同 Pod 运行。
• 允许扩展: 副本集允许对 Pod 进行扩展，调整应运行的 Pod 副本的数量。
• 很少直接使用: 虽然副本集是一个关键组件，但开发者通常不会直接与副本集交互。相反，它们通常通过部署间接管理。部署在副本集之上提供了一种声明式更新机制，管理起来更简单、更灵活。

解释和使用

• 部署与副本集的区别: 主要区别在于，部署是一个更高级的概念，它管理应用程序并处理更新的复杂性，而副本集仅专注于确保始终运行特定数量的 Pod。
• 使用情况: 对于大多数应用程序管理任务——如滚动更新和扩展——通常使用部署，因为它们提供了一个更全面的管理框架，包括管理副本集。副本集更多关注于维护所需状态和冗余。

对于我们的 pingpong 部署

        当我们使用 kubectl create deployment 命令创建 pingpong 部署时，这个过程触发了几个关键的步骤：

1. 创建部署（Deployment）:

   • 部署名称: deployment.apps/pingpong
   • 解释: 这个命令创建了一个名为 pingpong 的部署对象。在 Kubernetes 中，部署是管理一组相同应用实例的高级资源。部署控制器会监视所有属于该部署的副本集和 Pod，确保指定数量的 Pod 始终在运行。

2. 由部署创建副本集（Replica Set）:

   • 副本集名称: replicaset.apps/pingpong-xxxxxxxxxx
   • 解释: 部署自动创建了一个副本集。副本集是确保一定数量 Pod 副本同时运行的资源。这里的 xxxxxxxxxx 是自动生成的哈希值，用于唯一标识这个副本集。

3. 副本集创建 Pod:

   • Pod 名称: pod/pingpong-xxxxxxxxxx-yyyyy
   • 解释: 副本集负责创建和管理 Pod，确保始终有指定数量的 Pod 实例在运行。这里的 yyyyy 是额外的标识符，帮助进一步确保每个 Pod 的唯一性。

通俗解释：

这个过程可以想象成一个公司的组织结构：

• 部署 类似于公司的管理层，负责整体策略和目标的实现。
• 副本集 像是部门经理，确保其下的团队（Pod）成员数量符合要求，任何时间点都不多也不少。
• Pod 则是执行具体任务的员工，这里的任务就是执行 ping 命令来检测网络连接。

查看容器输出

在 Kubernetes 中，我们可以使用 kubectl logs 命令来查看 Pod 中容器的日志输出。这个命令非常有用，尤其是当我们需要调试或了解容器运行状态时。以下是如何使用这个命令的详细说明：

1. 基本命令用法:

   • 命令格式: kubectl logs [pod名称] 或者 kubectl logs [类型/名称]
   • 类型/名称: 如果指定类型和名称（如部署或副本集），命令将自动获取该资源中的第一个 Pod 的日志。

2. 查看特定容器的日志:

   • 默认行为: 如果没有另外指定，该命令默认只显示 Pod 中第一个容器的日志。
   • 选择容器: 如果 Pod 中有多个容器，可以通过增加 -c [容器名] 参数来指定要查看哪个容器的日志。

3. 实时流式查看日志:

   • 命令示例:

     $ kubectl logs deploy/pingpong --tail 1 --follow

   • 解释:
     • deploy/pingpong：指定查看名为 pingpong 的部署中容器的日志。
     • --tail 1：这个参数表示只显示最新的 1 行日志。
     • --follow：这个参数表示日志会持续输出到终端，允许你实时跟踪新产生的日志。

通俗解释：

使用 kubectl logs 命令查看日志就像是在看电视直播。通过 --follow 参数，你可以实时看到容器内部发生的事情，就如同实时观看新闻事件一样。这对于理解和监控你的应用程序在实际运行中的行为是非常有帮助的。而 --tail 参数则允许你调整你想一次性看到的日志量，类似于调整电视节目回放的起始点。

扩展我们的应用 

在 Kubernetes 中，我们可以通过 kubectl scale 命令来增加或减少容器（即 Pod）的副本数量，这对于调整应用以应对不同的负载非常有用。下面是如何扩展名为 pingpong 的部署的具体步骤：

1. 扩展部署:

   • 命令示例

     $ kubectl scale deploy/pingpong --replicas 8
     

   • 或者

     $ kubectl scale deployment pingpong --replicas 8
     

   • 解释:
     • deploy/pingpong 或 deployment pingpong：这指定了要扩展的部署的名称。
     • --replicas 8：这个参数设置了期望的副本数为 8，意味着 Kubernetes 将确保总共有 8 个运行中的 Pod 副本。

2. 尝试扩展副本集:

   • 思考:
     • 如果我们尝试直接扩展副本集，如 kubectl scale replicaset.apps/pingpong-xxxxxxxxxx --replicas 8，理论上这是可行的。
   • 后果:
     • 但部署会立即注意到这一变化，并将副本数调回到初始设定的水平。这是因为部署控制器管理着副本集和 Pod 的数量，它会确保配置的一致性。

3. 通俗解释：

   想象你在管理一个快餐连锁店，你决定在一个特别忙的区域增加更多的分店。使用 kubectl scale 命令增加 Pod 副本，就像是在这个区域开设更多的分店，以便更好地服务更多的客户。

   但如果你尝试只增加某个特定分店的规模而不通过总部的规划，总部会注意到这一点并可能撤回这一决定，将事情调整回原来的规模。这就像是部署（总部）控制并确保所有分店（副本集和 Pod）符合整体的战略规划。

弹性

在 Kubernetes 中，部署 (pingpong 部署) 通过监视其副本集来确保应用的稳定运行。副本集的任务是保证正确数量的 Pod 始终在运行。下面我们将探讨当 Pod 消失时会发生什么：

1. 监控 Pod:

   • 命令示例:

     $ kubectl get pods -w

   • 解释:
     • 这个命令会列出所有 Pod 并持续监视它们的状态。-w 参数使命令处于观察模式，实时显示所有更新。

2. 手动删除一个 Pod:

   • 命令示例:

     $ kubectl delete pod pingpong-xxxxxxxxxx-yyyyy

   • 解释:
     • 这个命令会删除一个指定的 Pod。pingpong-xxxxxxxxxx-yyyyy 是 Pod 的具体名称，其中 xxxxxxxxxx-yyyyy 是自动生成的标识符，确保每个 Pod 的唯一性。

发生了什么？

• 自动恢复:
  • 当一个 Pod 被删除后，副本集会注意到一个 Pod 缺失，并自动创建一个新的 Pod 来替换被删除的 Pod。这保证了 Pod 的数量始终符合部署指定的数量。
• 弹性表现:
  • 这种自动替换机制体现了 Kubernetes 的高弹性特性。系统能够自动检测和修复问题，无需人工干预，从而确保服务的持续可用性。

通俗解释：

你可以将这个过程想象为一个篮球队的教练在比赛中保持球队完整。如果一个球员（Pod）因伤离场，教练（副本集）会立即派一个替补球员进场，确保球队始终保持足够的人数参赛。这样做的目的是不论发生什么情况，球队都能继续比赛，表现出色。