学习 Kubernetes 基础知识

中级

USERS › APPLICATION DEVELOPER › INTERMEDIATE
Introduction
sections in this doc

Note: 阅读此文档前，假设您之前已经使用过 Kubernetes。此时，您应该拥有与 Kubernetes 集群(本地使用 Minikube 或者其他方式)交互的基本经验，并且使用如 Deployments 这样的 API 对象来运行您的应用程序。

如果没有请先首先阅读初级应用程序开发者
阅读完该页面及其相关链接后，您会对以下方面有更好的理解:

  • 除了 Deployments 之外的其他 Kubernetes 工作负载模式
  • 如何使 Kubernetes 应用生产程序就绪
  • 可以改善您开发工作流程的社区工具

学习其他的工作负载模式

随着您的 Kubernetes 使用案例变得更加复杂，您可能会发现工作负载模式有助于您熟悉 Kubernetes 提供的更多工具包。基本工作负载像

<a class='glossary-tooltip' href='/docs/concepts/workloads/controllers/deployment/' target='_blank'>Deployments<span class='tooltip-text'>Deployment 是管理应用副本的 API 对象。</span>

这样的对象可以直接运行，更新和扩展应用程序，但它们并不适用于所有场景。

以下 API 对象为其他工作负载类型提供功能，无论它们是*持久性的*还是*终止性*的。

持久性工作负载

像 Deployments 一样，这些 API 对象在集群上无限运行，直到它们被手动终止。它们最适合长期运行的应用程序。

<a class='glossary-tooltip' href='/docs/concepts/workloads/controllers/statefulset/' target='_blank'>StatefulSets<span class='tooltip-text'>StatefulSet 用来管理 Deployment 和伸缩一组 Pod，并且能为这些 Pod 提供*序号和唯一性保证*。</span>

** - 像 Deployments 一样, StatefulSets 允许您指定应该为您的应用程序运行一定数量的副本。 <!–

Note:

It’s misleading to say that Deployments can’t handle stateful workloads. Using

<a class='glossary-tooltip' href='/docs/concepts/storage/persistent-volumes/' target='_blank'>PersistentVolumes<span class='tooltip-text'>持久卷是代表集群中一块存储空间的 API 对象。 它是通用的、可插拔的、并且不受单个 Pod 生命周期约束的持久化资源。</span>

, you can persist data beyond the lifecycle of any individual Pod in your Deployment.

-->
Note:

说 Deployments 无法处理有状态的工作负载，这是不对的。使用

<a class='glossary-tooltip' href='/docs/concepts/storage/persistent-volumes/' target='_blank'>PersistentVolumes<span class='tooltip-text'>持久卷是代表集群中一块存储空间的 API 对象。 它是通用的、可插拔的、并且不受单个 Pod 生命周期约束的持久化资源。</span>

,您可以将数据保存在部署中任何单个 Pod 的生命周期之外。

<!-- However, StatefulSets can provide stronger guarantees about "recovery" behavior than Deployments. StatefulSets maintain a sticky, stable identity for their Pods. The following table provides some concrete examples of what this might look like: -->
但是，StatefulSets 可以提供比部署更强的“恢复”行为保证。StatefulSets 为其 Pod 保持一个粘性，稳定的身份。下表提供了一些具体示例:

<!-- |   | Deployment | StatefulSet |
|---|---|---|
| **Example Pod name** | `example-b1c4` | `example-0` |
| **When a Pod dies** | Reschedule on *any* node, with new name `example-a51z` | Reschedule on same node, as `example-0` |
| **When a node becomes unreachable** | Pod(s) are scheduled onto new node, with new names | Pod(s) are marked as "Unknown", and aren't rescheduled unless the Node object is forcefully deleted | -->
|   | Deployment | StatefulSet |
|---|---|---|
| **案例 Pod 名称** | `example-b1c4` | `example-0` |
| **Pod 消亡** | 使用新名称 `example-a51z` 重新安排*任何*节点 | 重新安排在同一节点上，如 `example-0` |
| **node 无法访问** | 使用新名称，将 Pod(s) 安排到新节点 | Pod(s) 被标记为"未知"，c除非强制删除 Node 对象，否则不会重新被安排 |

<!-- In practice, this means that StatefulSets are best suited for scenarios where replicas (Pods) need to coordinate their workloads in a strongly consistent manner. Guaranteeing an identity for each Pod helps avoid <a href="https://en.wikipedia.org/wiki/Split-brain_%28computing%29" target="_blank">split-brain</a> side effects in the case when a node becomes unreachable (<a href="https://en.wikipedia.org/wiki/Network_partition" target="_blank">network partition</a>). This makes StatefulSets a great fit for distributed datastores like Cassandra or Elasticsearch. -->
实际上，这意味着 StatefulSets 最适合副本 (Pods) 需要以强一致的方式协调其工作负载的场景。保证每个 Pod 的身份有助于避免 <a href="https://en.wikipedia.org/wiki/Split-brain_%28computing%29" target="_blank">脑裂</a> 副作用节点变得无法访问 (<a href="https://en.wikipedia.org/wiki/Network_partition" target="_blank">网络分区</a>)。这使得 StatefulSets 非常适合分布式数据存储，如 Cassandra 或 Elasticsearch 。

<a class='glossary-tooltip' href='/docs/concepts/workloads/controllers/daemonset' target='_blank'>DaemonSets<span class='tooltip-text'>确保 Pod 的副本在集群中的一组节点上运行。</span>

** - 即使添加或交换节点，DaemonSets 也会在集群中的每个节点上连续运行。该保证对于在群集中设置全局行为特别有用，例如: * 从 fluentd 等应用程序进行记录与监控 * 网络代理 或者 服务网格

终止性工作负载

与 Deployments 相比，这些 API 对象是有限的。一旦指定数量的 Pod 成功完成，它们就会停止。

<a class='glossary-tooltip' href='/docs/concepts/workloads/controllers/jobs-run-to-completion' target='_blank'>Jobs<span class='tooltip-text'>Job 是需要运行完成的确定性的或批量的任务。</span>

** -您可以将它们用于一次性任务，例如运行脚本或设置工作队列。这些任务可以顺序执行或并行执行。这些任务应当相对独立，因为 Jobs 不支持并行进程间密切交流。阅读更多关于任务模式。

<a class='glossary-tooltip' href='/docs/concepts/workloads/controllers/cron-jobs/' target='_blank'>CronJobs<span class='tooltip-text'>管理定期运行的 Job。</span>

** - CronJobs 与 Jobs 类似，但是它们允许您在特定的时间或者定期重复计划执行。您可以使用 CronJobs 发送提醒电子邮件或运行备份任务。它们的设置语法与*crontab*类似。

其他资源

有关详细信息，您可以查看其他 Kubernetes 资源类型列表以及 API 参考文档。

这里没有提到您可能会觉得有用的其他功能，这些功能在完整的 Kubernetes 文档 中有所介绍。

部署生产就绪的工作负载

这个网站上的初学者教程，例如留言簿应用, 目的是使工作负载在集群上启动并运行。这种原型设计非常适合在 Kubernetes 周围产生自己的见解！但是，为了可靠、安全地将工作负载推向生产，您需要遵循一些其他的最佳实践。

声明性配置

您可能通过

<a class='glossary-tooltip' href='/docs/user-guide/kubectl-overview/' target='_blank'>kubectl<span class='tooltip-text'>kubectl 是用来和 Kubernetes API 服务器进行通信的命令行工具。</span>

与您的 Kubernetes 集群进行通信。kubectl 可用于调试集群的当前状态(例如检查节点数)，或者修改实时 Kubernetes 对象(例如使用 kubectl scale 更新工作负载的副本计数)。

使用 kubectl 更新 Kubernetes 对象时，请务必注意不同的命令对应不同的方法：

虽然声明式配置(例如 kubectl apply -f )在生产中可能最有用，但每种方法都有利有弊。使用这种方法，您可以依赖本地 YAML 文件作为期望状态的来源。这使您可以对配置进行版本控制，这有助于代码审查和审计跟踪。

有关其他配置最佳做法，请熟悉指南。

安全

您可能熟悉最小特权原则 —如果您在编写或使用软件时过于宽松，那么折衷的负面影响可能会升级失控。您是否会谨慎地将“sudo”权限分配给您的操作系统上的软件？API服务器是集群真实来源的网关; 它提供端点来读取或修改集群状态。

您(或您的

<a class='glossary-tooltip' href='/zh/docs/reference/glossary/?all=true#term-cluster-operator' target='_blank'>集群管理员<span class='tooltip-text'>配置、控制、监控集群的人。</span>

)可以使用以下命令锁定 API 访问权限:

<a class='glossary-tooltip' href='/docs/tasks/configure-pod-container/configure-service-account/' target='_blank'>ServiceAccounts<span class='tooltip-text'>为在 Pod 中运行的进程提供标识。</span>

** - 您的 Pod 可以绑定的”身份”

<a class='glossary-tooltip' href='/docs/reference/access-authn-authz/rbac/' target='_blank'>RBAC<span class='tooltip-text'>管理授权决策，允许管理员通过 Kubernetes API 动态配置访问策略。</span>

** - 授予 ServiceAccount 显式权限的一种方式

有关安全性最佳实践的更全面的阅读，请考虑查看以下主题:

  • 认证(他们说的用户是谁?)
  • 授权(用户是否真的有权做他们要求的事情?)

资源隔离与管理

如果您的工作负载在具有多个团队或项目的*多租户*环境中运行，则容器不一定在其节点上单独运行。它们与您不拥有的其他容器共享节点资源。

即使您的集群运营者代表您管理集群，了解以下内容会对你有帮助:

<a class='glossary-tooltip' href='/docs/concepts/overview/working-with-objects/namespaces' target='_blank'>命名空间<span class='tooltip-text'>命名空间是 Kubernetes 为了在同一物理集群上支持多个虚拟集群而使用的一种抽象。</span>

**, 用于隔离 * 资源配额, 影响团队的工作负载 * 内存 and CPU requests, 对于给定的 Pod 或容器请求 * 监视, 集群级和应用级

这个清单可能并不完全全面，但许多团队都有处理所有这些问题的现有流程。如果不是这样，您会发现 Kubernetes 文档非常详细。

使用工具改进开发工作流程

作为 app 开发者，您可能会在工作流中遇到以下工具。

kubectl

kubectl 是一个命令行工具，它允许您轻松读取或修改 Kubernetes 集群。它为常见操作(如缩放 app 应用程序实例和获取节点信息)提供了方便快捷的命令。 kubectl 是怎么做到的？它基本上仅仅是一个用于发出 API 请求的用户友好的包装器。它是使用client-go编写的，这是 Kubernetes API 的 go 库。

要了解最常用的 kubectl 命令，请查看kubectl 目录。它解释了以下主题:

有关 kubectl 命令及其选项的完整列表，请查看 参考指南。

Helm

要利用来自社区的预打包配置，可以使用 **

<a class='glossary-tooltip' href='https://github.com/kubernetes/helm/blob/master/docs/charts.md' target='_blank'>Helm charts<span class='tooltip-text'>Helm Chart 是一组预先配置的 Kubernetes 资源所构成的包，可以使用 Helm 工具对其进行管理。</span>

**。

Helm 图表为 Jenkins 和 Postgres 等特定应用 apps 打包了 YAML 配置文件。然后，您只需进行最少的额外配置，就可以在集群上安装和运行这些应用 apps。这种方法对于不需要很多自定义实现逻辑的“现成”组件最有意义。

对于编写自己的 Kubernetes 应用程序配置文件，有一个强大的工具生态系统链接，您可能会发现它很有用。

探索其他资源

参考

现在您已经相当熟悉 kubernetes，您可能会发现浏览下面的参考页很有用。这样做提供了可能存在的其他功能的高层次视图:

此外，Kubernetes 博客 经常有关于 Kubernetes 设计模式和案例研究的有用文章。

接下来

如果您对本页中的话题感到相当满意，并希望了解更多信息，请查看以下用户旅程:

反馈