在微服务、云计算和无服务架构时代，了解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里盘根错节的组件架构。