来说说Kubernetes的运作机制

1. 来说说Kubernetes的运作机制

| 启迪云解决方案架构师 费海强
    
 容器非常轻巧灵活，它们产生了新的应用程序架构，新方法是将构成应用程序的不同服务打包到单独的容器中，并在物理或虚拟机群集中部署这些容器。这就需要容器编排 - 一种自动化基于容器的应用程序的部署，管理，扩展，网络和可用性的工具。
  
 Kubernetes，这个源自Google的开源项目可以自动化大规模部署和管理多容器应用程序的过程，虽然Kubernetes主要使用Docker，但它也适用于符合容器图像格式和运行时的Open Container Initiative（OCI）标准的任何容器系统。而且由于Kubernetes是开源的，对其使用方式的限制相对较少，任何想要运行容器的人都可以自由使用它。
  
 Kubernetes不会取代Docker，但会增加它的功能，但是，Kubernetes 确实取代了Docker中出现的一些更高级别的技术。
  
 其中一种技术是Docker Swarm，一个与Docker捆绑在一起的编排器，它仍然可以使用Swarm而不是Kubernetes，但Docker公司已经选择让Kubernetes成为Docker社区和Docker Enterprise版本的一部分。
  
 并不是说Kubernetes是Swarm的直接替代品。Kubernetes比Swarm复杂得多，需要更多的工作才能部署，但同样，这项工作旨在从长远来看提供巨大的回报- 一个更易于管理，更具弹性的应用程序基础架构。对于开发工作和较小的容器集群，Docker Swarm提供了一个更简单的选择。
  
 高级语言（如Python或C＃）为用户提供抽象和库，以便他们可以专注于完成手头的任务，而不是陷入内存管理的细节。
  
 Kubernetes与容器编排的工作方式相同，它为管理容器组提供了高级抽象，允许Kubernetes用户专注于他们期待的应用程序运行方式，而不是担心具体的实现细节。他们需要的行为与提供它们的组件分离。
  
 许多应用程序不仅存在于一个容器中，它们是由一堆容器构建，可能是一个数据库，或是Web前端，也许是一个缓存服务器。微服务也是以这种方式构建的，通常为每个服务、Web协议和API绘制单独的数据库，以将服务联系在一起。虽然将应用程序作为微服务来构建有长期的优势，但它带来了许多短期的繁重工作。
  
 Kubernetes减少了实现此类应用程序所需的工作量，你告诉Kubernetes如何从一组容器中组成一个应用程序，Kubernetes处理将它们推出，保持它们运行并保持组件彼此同步的细节。
  
 应用程序需要能够上下调整以满足需求，平衡传入负载，并更好地利用物理资源。Kubernetes具备做所有这些事情的条件，并以自动化，不干涉的方式进行。
  
 基于容器的应用程序开发工作流程的部分吸引力在于实现持续集成和交付，Kubernetes具有允许对新版本的容器映像进行优雅更新的机制，包括在出现问题时进行回滚。
  
 Kubernetes处理许多其他基于容器的应用程序的复杂细节，让容器相互通信，处理服务发现以及为来自各种提供商（例如，亚马逊的EBS）的容器提供持久存储都通过Kubernetes及其API进行处理。
  
 众所周知，容器是不透明的。Kubernetes提供用于获取有关容器和容器组状态的实时信息的服务，以及有关群集中开发人员操作的详细信息。
  
 Kubernetes集群可能需要调整其目标环境，但一些调整会使未来的升级变得困难。Kubernetes的本机功能之一，自定义资源定义，允许开发人员扩展和自定义Kubernetes的API，而不会破坏与Kubernetes库存的兼容性。
  
 Kubernetes与特定的云环境或技术无关，它可以在任何支持容器的地方运行，这意味着公共云，私有堆栈，虚拟和物理硬件以及单个开发人员的笔记本电脑都是Kubernetes可以玩的地方。Kubernetes集群也可以运行上述任何组合。这甚至包括Windows和Linux系统的混合。
  
 Kubernetes的架构利用了各种概念和抽象，其中一些是现有的，熟悉的概念的变体，但其他一些是Kubernetes特有的。
  
 最高级别的Kubernetes抽象（cluster）是指运行Kubernetes（本身是集群应用程序）的一组机器及其管理的容器，一个Kubernetes集群必须有一个master，即命令和控制集群中所有其他Kubernetes机器的系统。一个高可用性的Kubernetes集群在多台机器上复制master的设施，但一次只有一个主控形状运行作业调度程序和控制器管理器。
  
 每个集群都包含Kubernetes节点，节点可以是物理机器或虚拟机，同样，这个想法是抽象的：无论应用程序运行在什么地方，Kubernetes都会处理在那个底层上的部署。还可以确保某些容器仅在虚拟机上运行或仅在裸金属上运行。
    
 根据需要在节点上创建和销毁pods，以符合用户在pod定义中指定的所需状态。Kubernetes提供了一个称为控制器的抽象概念，用于处理如何旋转、展开和旋转pods的物流。控制器有几种不同的风格，这取决于所管理的应用程序的类型。例如，最近引入的“StatefulSet”控制器用于处理需要持久状态的应用程序。另一种控制器，部署，用于向上或向下扩展应用程序，将应用程序更新为新版本，或者在出现问题时将应用程序回滚到已知的良好版本。
  
 因为pods根据需要生存和死亡，我们需要一个不同的抽象来处理应用程序生命周期。应用程序应该是一个持久化实体，即使运行构成应用程序的容器的pod本身不是持久的。为此，Kubernetes提供了一种称为服务的抽象。
  
 服务描述了如何通过网络访问给定的pod组（或其他Kubernetes对象），正如Kubernetes文档所说，构成应用程序后端的pod可能会发生变化，但前端不应该知道或跟踪它。服务使这成为可能。
  
 Kubernetes内部的一些内容使图片更加完美，该调度包裹了工作量，以使他们在整个资源平衡和使部署满足应用程序定义的要求节点。所述控制器管理器保证了系统的应用程序，工作负载，状态等-匹配ETCD的配置设置定义的期望的状态。
  
 重要的是要记住，容器使用的低级机制（如Docker本身）都不会被Kubernetes 取代。相反，为了保持应用程序大规模运行，Kubernetes提供了一组更大的抽象来使用它们。

2. 十分钟了解kubernetes的核心概念

 下文将简单介绍 kubernetes 的核心概念。因为这些定义可以 kubernetes 的官档中找到， 中文文档地址 ，所以下文中也会避免用大段枯燥的文字介绍。相反，我们会使用一些图表和示例来解释这些概念，借助它们我们可以全面理解晦涩难懂的一些概念。
    kubernetes （k8s）是自动化容器操作的开源平台，这些操作包括布署，调度和节点集群间扩展。如果你曾经用docker容器技术布署容器，那么可以将docker看成kubernetes内部使用的低级别组件。kubernetes不仅仅支持docker，还支持rocker（另一种容器技术）。
   使用kubernetes拥有下面的特点：
   实际上，kubernetes只需一个部署文件，使用一条命里就可以布署多层容器（前后端）的完整集群。
   集群是一组节段，这些节点可以是物理服务器或者虚拟机，之上安装了kubernetes平台。下图展示这样的集群，注意概图为了强调核心概念有所简化。
                                           上图可以看到如下组件，使用特别的图标表示Service和Label：
   Pod（上图绿色框）安排在节点上，包括一组容器和卷。同一个Pod里面的容器共享一个命名网络空间，可以使用localhost互相通信。Pod是短暂的，不是持续性实体。你可以有下面的问题：
   如上图所示，一些Pod有Label。一个Label是attach到Pod的一对键值对，用来传递用户定义的属性。比如你可能创建了一个"tier"和"app"标签，通过Label(tier=frontend, app=myapp)来标记前端Pod容器，使用Label(tier=backend, app=myapp)标记后台容器，然后可以使用Seletors选择带有特定标签Label的Pod，并且将Service或Replication Controller应用到上面。
   是否手动创建Pod，如果想要创建同一个容器的多份拷贝，需要一个个分别创建出来么？能否将Pods划分到逻辑组里面去。
   Replication Controller确保任意时间都有着指定数量的Pod副本在运行。如果为某个Pod创建了Replication Controller并制定3个副本，它会创建3个副本，并且持续监控它们。如果某个Pod不响应，那么Replication Controller会替换它，
                                           如果之前不响应的Pod恢复了，现在就有了4个Pod，那么Replication Controller就会将其中一个终止并保持总数为3。如果在运行中将副本总数改为5，Replication Controller就会立即启动2个新的Pod，保证总数为5。还可以按照这样的方式缩小Pod，这个特性在执行滚动升级时比较有用。
   当创建Replication Controller时，需要执行两个东西：
   现在已经创建了Pod的副本，那么在这些副本上如何进行均衡负载？我们需要的是Service。
   如果Pods是短暂的。那么重启时IP地址可能会发生变化，怎么才能从前端容器正确可靠的指向后端容器呢？
    Service是定义一些列Pod以及访问这些Pod的策略的一层抽象。 Service通过Label找到Pod组。因为Service是抽象的，所以在图表中通常看不到它们的存在，这也就让这一概念更难理解。
   现在，假定有两个后台Pod，并定义后台Service的名称为‘backend-service’，label选择器为（tier=backend, app=myapp）。backend-service会完成如下两件重要的事情：
   下图动画展示了Service的功能。注意该图做了很多简化。如果不进入网络配置，那么达到透明的负载均衡目标所涉及的底层网络和路由相对先进。
                                           有一个特别类型的Kubernetes Service，称为‘LoadBlancer’，作为外部负载均衡器使用，在一定数量的Pod之间负暂均衡。
   节点（上橘色方框）是物理机或虚拟机，作为kubernetes worker，通常称为Minion。每个节点都运行如下Kubernetes关键组件：
   集群拥有一个Kubernetes Master（紫色方框）。Kubernetes Master提供集群的独特视角，并且拥有一系列组件，如Kubernetes API Service。API Server提供可以用来和集群交互的REST端点。master节点包括用来创建和复制Pod的Replication Controller。
    十分钟带你理解Kubernetes核心概念 
   再下面会继续理解属于和概念，最后尝试使用。