浅入kubernetes(2)：Kubernetes 的组成
<p></p><div class="toc"><div class="toc-container-header">目录</div><ul><li>说明</li><li>Kubernetes集群的组成</li><li>What are containerized applications?</li><li>What are Kubernetes containers?</li><li>What are Kubernetes pods?</li><li>What is the difference between containers vs. pods?</li><li>What are Kubernetes nodes?<ul><li>What is the difference between Kubernetes pods vs. nodes?</li></ul></li><li>What is a Kubernetes Control Plane?</li><li>What is a Kubernetes Cluster?<ul><li>What is the difference between Kubernetes Nodes vs. Clusters?</li></ul></li><li>What are Kubernetes volumes?</li><li>How do the components of Kubernetes work together?</li></ul></div><p></p><h3 id="说明">说明</h3>
<p>本本内容从 https://www.vmware.com/topics/glossary 获取、翻译，网站内容政策请参考 https://www.vmware.com/community_terms.html，内容复制、翻译请参考版权协议 http://creativecommons.org/licenses/by-nc/3.0/。</p>
<p>本文内容从 vmware 网站的术语词汇知识库收集、翻译、整理，文章主要介绍 Kubernetes 各组成部件中的一些术语，以及概念。</p>
<h3 id="kubernetes集群的组成">Kubernetes集群的组成</h3>
<p>我们谈起 Kubernetes 和应用部署时，往往会涉及到容器、节点、Pods 等概念，还有各种术语，令人眼花缭乱。为了更好地摸清 Kubernetes，下面我们将介绍 Kubernetes 中与应用程序部署(deployment)和执行(execution)相关的知识。</p>
<p>Kubernetes 集群由多个组件(components)、硬件(hardware)、软件(software)组成，它们共同工作来管理容器化(containerized)应用的部署和执行，这些相关的组成的概念有：</p>
<table>
<thead>
<tr>
<th>成分</th>
<th>名称</th>
</tr>
</thead>
<tbody>
<tr>
<td>Cluster</td>
<td>集群</td>
</tr>
<tr>
<td>Node</td>
<td>节点</td>
</tr>
<tr>
<td>Pod</td>
<td>不翻译</td>
</tr>
<tr>
<td>Container</td>
<td>容器</td>
</tr>
<tr>
<td>Containerzed Application</td>
<td>容器化应用</td>
</tr>
</tbody>
</table>
<p>接下来的内容，按将从小到大的粒度介绍这些组成成分。</p>
<h3 id="what-are-containerized-applications">What are containerized applications?</h3>
<p>containerized applications 指容器化的应用，我们常常说使用镜像打包应用程序，使用 Docker 发布、部署应用程序，那么当你的应用成功在 Docker 上运行时，称这个应用是 containerized applications。</p>
<p>定义：</p>
<p><em>Containerized applications are bundled with their required libraries, binaries, and configuration files into a container.</em></p>
<p><em>容器化的应用程序与它们所需的库、二进制文件和配置文件绑定到一个容器中。</em></p>
<p>当然，并不是说能够将一个应用程序打包到容器中运行，就可以鼓吹产品；并不是每个应用程序都是容器化的优秀对象，例如在 DDD 设计中被称为大泥球的应用程序，由于其设计复杂、依赖程度高、程序不稳定等原因，难以迁移、难以配置的应用程序明显是失败的产品。</p>
<p>在多年经验中，许多开发者总结了经验，形成十二个云计算应用程序因素指导原则：</p>
<p><strong>1. Codebase:</strong> One codebase tracked in revision control, many deploys</p>
<p> 代码库: 一个代码库可以在版本控制和多份部署中被跟踪</p>
<p><strong>2. Dependencies:</strong> Explicitly declare and isolate dependencies</p>
<p>依赖项: 显式声明和隔离依赖项</p>
<p><strong>3. Config:</strong> Store config in the environment</p>
<p>配置: 在环境中存储配置</p>
<p><strong>4. Backing services:</strong> Treat backing services as attached resources</p>
<p>支持服务: 将支持服务视为附加资源(可拓展，而不是做成大泥球)</p>
<p><strong>5. Build, release, run:</strong> Strictly separate build and run stages</p>
<p>构建、发布、运行: 严格区分构建和运行阶段(连 Debug、Release 都没有区分的产品是真的垃圾)</p>
<p><strong>6. Processes:</strong> Execute the app as one or more stateless processes</p>
<p>过程: 作为一个或多个无状态过程执行应用程序</p>
<p><strong>7. Port binding:</strong> Export services via port binding</p>
<p>端口绑定: 可通过端口绑定服务对外提供服务</p>
<p><strong>8. Concurrency</strong>: Scale out via the process model</p>
<p>并发性: 通过进程模型进行扩展</p>
<p><strong>9. Disposability:</strong> Maximize robustness with fast startup and graceful shutdown</p>
<p>可处理性: 快速启动和完美关机，最大限度地增强健壮性</p>
<p><strong>10. Dev/prod parity</strong>: Keep development, staging, and production as similar as possible</p>
<p>Dev/prod parity: 尽可能保持开发中、演示时和生产时的相似性</p>
<p><strong>11. Logs:</strong> Treat logs as event streams</p>
<p>Logs: 将日志视为事件流</p>
<p><strong>12. Admin processes:</strong> Run admin/management tasks as one-off processes</p>
<p>管理流程: 将管理/管理任务作为一次性流程运行</p>
<p>上述内容可能有笔者翻译不到位的地方，读者可阅读原文了解：</p>
<p>https://www.vmware.com/topics/glossary/content/components-kubernetes</p>
<p>许多流行的编程语言和应用被容器化并存储在开源仓库中，然而，只使用运行应用程序所需的库和二进制文件来构建应用程序容器，不需要导入所有可用的东西，这样可能会更有效率。创建容器可以采用编程方式，从而可以创建持续集成和部署(CI/CD)管道以提高效率。容器化应用位于开发人员领域之中，开发人员需要掌握如何容器化应用。</p>
<h3 id="what-are-kubernetes-containers">What are Kubernetes containers?</h3>
<p><em>Containers are standardized, self-contained execution enclosures for applications.</em></p>
<p>容器是应用的标准化、独立的执行外壳。</p>
<p>通常，容器都包含一个应用程序，以及正确执行二进制程序所需的依赖库、文件等，例如 Linux 文件系统+应用程序组成一个简单的容器。通过将容器限制为单个进程，问题诊断和更新应用程序都变得更加容易。与 VM(虚拟机)不同，容器不包含底层操作系统，因此容器被认为是轻量级的。Kubernentes 容器属于开发领域。</p>
<h3 id="what-are-kubernetes-pods">What are Kubernetes pods?</h3>
<p>Pod 是 Kubernetes 集群中最小的执行单位。在 Kubernetes 中，容器不直接在集群节点上运行，而是将一个或多个容器封装在一个 Pod 中。Pod 中的所有应用程序共享相同的资源和本地网络，从而简化了 Pod 中应用程序之间的通讯。Pod 在每个节点(Node)上利用一个名为 Kubelet 的代理和 Kubernetes API 以及集群中其余部分进行通讯。尽管现在开发人员需要 API 访问完成集群管理，但 Pod 的管理是正在向 Devops 领域过渡。</p>
<p>随着 Pod 负载的增加，Kubernetes 可以自动复制 Pod 以达到预期的可拓展性(部署更多的 Pod 提供相同的服务，负载均衡)。因此，设计一个尽可能精简的 Pod 是很重要的，降低因复制扩容、减少收缩过程中带来的资源损失。</p>
<p>Pod 似乎被认为是 DevOps 的专业领域。</p>
<h3 id="what-is-the-difference-between-containers-vs-pods">What is the difference between containers vs. pods?</h3>
<p>容器包含执行特定流程或函数所需的代码(编译后的二进制可执行程序)。在 Kubernetes 之前，组织可以直接在物理或虚拟服务器上运行容器，但是缺乏 Kubernetes 集群所提供的可伸缩性和灵活性。</p>
<p>Pod 为容器提供了一种抽象，可以将一个或多个应用程序包装到一个 Pod 中，而 Pod 是 Kubernetes 集群中最小的执行单元。例如 Pod 可以包含初始化容器，这些容器为其它应用提供了准备环境，然后在应用程序开始执行前终结。Pod 是集群中复制的最小单位，Pod 中的容器作为整体被扩展或缩小。</p>
<p>如果应用程序需要访问持久性的存储，那么 Pod 也包括持久性存储和容器。</p>
<h3 id="what-are-kubernetes-nodes">What are Kubernetes nodes?</h3>
<p>Pod 是 Kubernetes 中最小的执行单元，而 Node 是 Kubernetes 中最小的计算硬件单元。节点可以是物理的本地服务器，也可以是虚拟机。</p>
<p>与容器一样，Node 提供了一个抽象层。如果操作团队认为一个 Node 只是一个具有处理能力和内存的资源，那么每个 Node 就可以与下一个 Node 互换。多个 Node 一起工作形成了 Kubernetes 集群，它可以根据需求的变化自动分配工作负载。如果一个节点失败，它将自动从集群中移除，由其他节点接管。每个节点都运行着一个名为 kubelet 的代理，该代理与集群控制平面通信。</p>
<p>Node 是 DevOps 和 IT 的专业领域。</p>
<h4 id="what-is-the-difference-between-kubernetes-pods-vs-nodes">What is the difference between Kubernetes pods vs. nodes?</h4>
<p>Pod 是可执行代码的抽象，Node 是计算机硬件的抽象，所以这种比较有点像苹果和橘子。</p>
<p>Pods 是 Kubernetes 最小的执行单元，由一个或多个容器组成；</p>
<p>Node 是组成 Kubernetes 集群的物理服务器或虚拟机。Node 是可互换的，通常不会由用户或 IT 单独处理，除非需要进行维护。</p>
<h3 id="what-is-a-kubernetes-control-plane">What is a Kubernetes Control Plane?</h3>
<p>Kubernetes 控制平面是用于 Kubernetes 集群的控制器，主要包含 <strong>apiserver</strong>、<strong>etcd</strong>、<strong>scheduler</strong>、<strong>controller-manager</strong> 。</p>
<p>在第一篇时已经提到过，这里不需要深入介绍，故不再赘述。</p>
<p><img src="https://img2020.cnblogs.com/blog/1315495/202101/1315495-20210104222435824-1879446607.png" alt="Kubernetes_Architecture_graphic" loading="lazy"></p>
<p><img src="https://img2020.cnblogs.com/blog/1315495/202101/1315495-20210104222451356-2080442765.png" alt="rancher-k8s-node-components-architecture" loading="lazy"></p>
<h3 id="what-is-a-kubernetes-cluster">What is a Kubernetes Cluster?</h3>
<p>Kubernetes 集群由 Node 组成，Node 可以是虚拟机或物理服务器。当你使用 Kubernetes 时，大多时间是在管理集群。在一个 Node 上必须至少有一个运行的 Kubernetes 控制平面的实例，以及至少一个要在其上运行的 Pod。通常，当工作负载发生变化时，集群将有多个节点来处理应用程序的变更。</p>
<h4 id="what-is-the-difference-between-kubernetes-nodes-vs-clusters">What is the difference between Kubernetes Nodes vs. Clusters?</h4>
<p>Node 是集群中最小的元素。集群由 Node 组成。集群是一个集体，共享 Pod 的总体执行，反映在 Google Kubernetes 集群项目的原始名称:Borg。</p>
<h3 id="what-are-kubernetes-volumes">What are Kubernetes volumes?</h3>
<p>由于容器最初设计为临时性和无状态的，因此几乎不需要解决存储持久性问题。然而，随着越来越多需要从持久性存储读写的应用程序被容器化，对持久性存储卷的访问需求也随之出现。</p>
<p>为了实现这一点，Kubernetes 有持久的卷。独特之处在于它们是集群外部的，可以将持久卷挂载到集群，而不需要将它们与特定节点、容器或 pod 关联。</p>
<p>持久卷可以是本地的，也可以是基于云的，并且是 DevOps 和 IT 的专业领域。</p>
<p>在 Docker 中，我们可以使用以下命令管理卷</p>
<pre><code># 创建自定义容器卷
docker volume create {卷名称}
</code></pre>
<pre><code># 查看所有容器卷
docker volume ls
</code></pre>
<pre><code># 查看指定容器卷的详细信息
docker volume inspect {卷名称}
</code></pre>
<p>我们可以在运行容器时，使用 <code>-v</code> 映射主机目录，或者映射容器卷到容器中。</p>
<pre><code>docker -itd ... -v /var/tmp:/opt/app ...
docker -itd ... -v {卷名}:/opt/app ...
</code></pre>
<h3 id="how-do-the-components-of-kubernetes-work-together">How do the components of Kubernetes work together?</h3>
<p>简单地说，刚开始时，应用程序被创建或迁移到容器中，然后运行在 Kubernetes 集群创建的 Pod上。</p>
<p>一旦 Pod 被创建，Kubernetes 会将它们分配给集群中的一个或多个 Node ，并确保运行的副本 Node 的正确数量。Kubernetes 扫描集群以确保每组 Container 都按照指定的方式运行。</p>
</div>
<div id="MySignature" role="contentinfo">
痴者工良(https://whuanle.cn)<br><br>
来源：https://www.cnblogs.com/whuanle/p/14232932.html
頁:
[1]