共计 4004 个字符，预计需要花费 11 分钟才能阅读完成。
在微服务、云计算和无服务架构时代，了解 Kubernetes 并且晓得如何应用它是非常有用的。然而，官网的 Kubernetes 文档对于刚开始接触云计算的用户来说有些难以了解。在本文中，咱们将理解在 Kubernetes 中的重要概念。在之后的系列文章中，咱们还将理解如何写配置文件、应用 Helm 作为软件包管理器、创立一个云基础架构、应用 Kubernetes 轻松编排服务并且创立一个 CI/CD 流水线来自动化整个工作流。有了这些信息，你能够启动任意品种的我的项目，并且创立一个弱小的基础架构。
首先，咱们晓得应用容器有多种益处，从部署速度的晋升到大规模一致性交付等。即使如此，容器也并非所有问题的解决之道，因为应用容器会带来肯定的开销，比方保护一个容器编排层。所以，你须要在我的项目开始的时候剖析老本 / 效益。
当初，让咱们开启 Kubernetes 世界之旅吧！
Kubernetes 硬件构造
节点
节点是 Kubernetes 中的 worker 机器，能够是任何具备 CPU 和 RAM 的设施。例如，智能手表、智能手机或者笔记本，甚至是树莓派都能够成为一个节点。当咱们应用云时，节点就是一个虚拟机（VM）。所以，简略来说，节点是繁多设施的抽象概念。这种形象的益处是，咱们不须要晓得底层的硬件构造。咱们只应用节点，这样一来，咱们的基础设施就独立于平台。
集群
一个集群是一组节点。当你将程序部署到集群上时，它会主动将工作调配到各个节点。如果须要更多的资源（简略来讲，咱们须要更多钱），那么集群中将会退出新的节点并且将会主动重新分配工作。
咱们在集群上运行咱们的代码，但咱们不须要关怀具体在哪个节点上运行了哪局部的代码。工作的调配是主动的。
长久卷（persistent volumes）
因为咱们的代码能够从一个节点转移到另一个节点（例如，某个节点没有足够的内存，那么工作将会被从新调度到另一个领有短缺内存的节点上），所以在节点上保留数据容易失落。如果咱们想要永恒保留咱们的数据，咱们应该应用长久卷。长久卷有点相似内部的硬盘，你能够将它插入并在下面保留你的数据。
Google 开发的 Kubernetes 是一个无状态应用程序的平台，其持久性数据存储在其余中央。当这一我的项目倒退成熟之后，许多企业想要在有状态应用程序中应用它，所以开发人员须要增加长久卷治理。如同晚期的虚拟化技术，数据库 server 通常状况下并不是首要迁徙到新架构下来的 server。这是因为数据库是许多应用程序的外围，并且可能蕴含很多重要信息，所以本地数据库系统在虚拟机或物理机中通常规模很大。
所以，问题是，咱们应该什么时候开始应用长久卷？要答复这个问题，首先，咱们应该了解数据库利用的不同类型。
咱们将数据管理解决方案分为以下两类：
- 垂直伸缩——包含传统的 RDMS 解决方案，例如 MySQL、PostgreSQL 以及 SQL Server
- 程度伸缩——包含“NoSQL”解决方案，例如 ElasticSearch 或基于 Hadoop 的解决方案
垂直伸缩解决方案（如 MySQL、PostgreSQL 以及 Microsoft SQL）不应该利用在容器内。这些数据库平台要求高 I /O、共享磁盘以及 block 存储等，并且无奈解决集群内的节点失落，但这一状况经常会产生在基于容器的生态系统内。
对于程度伸缩应用程序（如 Elastic、Cassanda、Kafka 等）能够应用容器。他们可能接受数据库集群内的节点失落以及数据库利用能够自行复原平衡。
通常状况下，你应该容器化分布式数据库，从而利用冗余的存储技术并且可能解决数据库集群内的节点失落（ElasticSearch 是一个很好的例子）。
Kubernetes 软件组件
容器
古代软件开发的指标之一是保障各类应用程序在雷同的主机或集群上能够彼此隔离。虚拟机是解决该问题的一个计划。但虚拟机须要他们本人的操作系统，所以他们的规模通常是千兆字节。
容器则恰恰相反，它能够隔离应用程序的执行环境但共享底层操作系统。所以，容器就像一个盒子，咱们能够在其中保留所有运行应用程序所须要的：代码、运行时、零碎工具、零碎仓库、设置等。它们通常仅须要几兆字节即可运行，远远少于虚拟机所需资源，并且能够立刻启动。
Pods
Pod 是一组容器。在 Kubernetes 中，最小的单位是 Pod。一个 pod 能够蕴含多个容器，但通常状况下咱们在每个 pod 中仅应用一个容器，因为在 Kubernetes 中最小复制单位是 pod。如果咱们想要为每个容器独自扩容，咱们增加一个容器到 Pod 中即可。
Deployments
Deployment 的最后性能是为 pod 和 ReplicaSet（雷同 Pod 在其中会被复制很屡次）提供申明式更新。应用 deployment，咱们能够指定有多少雷同 pod 的正本应该随时运行。Deployment 相似于 pod 的管理器，它能够主动启动所需数量的 pod、监控 pod 并在呈现故障时从新创立 Pod。Deployment 极其有用，因为你不须要独自创立和治理每个 pod。
咱们通常为无状态应用程序应用 deployment。然而，你能够通过给他附加一个长久卷来残存 deployment 的状态并使其变得有状态。
Stateful Sets
StatefulSet 是 Kubernetes 中的一个新概念并且它是用于治理有状态利用的资源。它治理 deployment 和一组 pod 的扩大，并且确保这些 pod 的程序以及独特性。它与 deployment 相似，惟一的区别是 deployment 创立一组任意名称的 pod，并且 pod 的程序对它来说并不重要，而 StatefulSet 创立的 pod 都有举世无双的名称以及程序。所以，如果你想为名为 example 的 pod 创立 3 个正本，那么 StatefulSet 将会创立为：example-0、example-1、example-2。因而，这一创立形式最重要的益处就是你能够通过 pod 的名称就理解大抵的状况。
DaemonSets
DaemonSet 能够确保 pod 运行在集群的所有节点上。如果从集群中增加 / 移除了一个节点，DaemonSet 会主动增加 / 删除该 pod。这对于监控以及日志非常重要，因为你能够监控每个节点并且不须要手动监控集群。
Services
Deployment 负责放弃一组 Pod 处于运行状态，那么 Service 负责为一组 Pod 启动网络拜访。Services 能够跨集群提供标准化的个性：负载平衡、利用间的服务发现以及零宕机应用程序 deployment。每个服务都有举世无双的 IP 地址以及 DNS 主机名称。能够为须要应用服务的应用程序手动配置相应的 IP 地址或主机名称，而后流量将会被负载平衡到正确的 pod。在内部流量的局部，咱们会理解到更多的服务类型以及咱们如何在外部服务和内部世界间进行通信。
ConfigMaps
如果你想部署到多个环境中，如 staging、开发环境和生产环境，bake 配置到应用程序中并不是一个好的操作，因为环境之间存在差异性。现实情况下，你会心愿每个部署环境对应不同的配置。于是，ConfigMap 应运而生。ConfigMaps 能够让你从镜像中解耦配置工件以放弃容器化应用程序的便携性。
内部流量
既然你曾经理解运行在集群中的服务，那么你如何获取内部流量到你的集群中呢？有三种服务类型能够解决内部流量：ClusterIP、NodePort 以及 LoadBalancer。还有第 4 种解决方案：再增加一个形象层，称为 Ingress Controller。
ClusterIP
ClusterIP 是 Kubernetes 中默认的服务类型，它能够让你在集群外部与其余服务进行通信。尽管 ClusterIP 不是为内部拜访而设计的，但只有应用代理进行了一些改变，内部流量就能够拜访咱们的服务。不要在生产环境中采纳这一解决方案，但能够用其来进行调试。申明为 ClusterIP 的服务不应该能够从内部间接可见。
NodePort
正如咱们在本文第一局部中所看到的那样，pod 正在节点上运行。节点能够是各种不同的设施，如笔记本电脑或虚拟机（但在云端运行时）。每个节点有一个固定的 IP 地址。通过将一个服务申明为 NodePort，服务将会裸露节点 IP 地址，以便你能够从内部拜访它。你能够在生产环境中应用 NodePort，但对于领有许多服务的大型应用程序来说，手动治理所有不同的 IP 地址非常麻烦。
LoadBalancer
申明一个 LoadBalancer 类型的服务，就能够应用云提供商的 LoadBalancer 向内部公开。内部 load balancer 如何将流量路由到服务 Pod 取决于集群提供程序。有了这个解决方案，你不用治理集群中每个节点的所有 IP 地址，但你将为每个服务装备一个 load balancer。毛病是，每个服务都有一个独自的 load balancer，你将依照 load balancer 实例付费。
这一解决方案实用于生产环境，但它有些低廉。接下来，咱们来看看略微便宜一些的解决方案。
Ingress
Ingress 不是一个服务，而是一个 API 对象，它能够治理内部对集群服务的拜访。它作为反向代理和繁多入口点（entry point）进入你的集群，将申请路由到不同的服务。我通常应用 NGINX Ingress Controller，它承当了反向代理，同时也作为 SSL 发挥作用。裸露 ingress 的最佳生产计划是应用一个 load balancer。
借助这一解决方案，你能够应用单个 load balancer 裸露任意数量的服务，所以你能够让费用放弃在最低水平。
总结
在本文中，咱们理解了 Kubernetes 中的基本概念及其硬件架构。咱们还探讨了不同的软件组件，如 Pod、Deployment、StatefulSets 以及 Services，并且理解了服务与内部世界之间如何进行通信。心愿能够帮忙你再次梳理 Kubernetes 里盘根错节的组件架构。
