课程概要
Kubernetes脱胎于Google的Borg系统，是个功能强大的容器编排系统。目前已成为开发者、运维人员中最流行的开发工具。本文从Kubernetes的主要组成部分和主要资源类型出发，简要讲解Kubernetes的基本技术原理。同时全面分析POD、Deployment、Service等主要组成资源，并且结合案例展现其基本应用方法。
Kubernetes的由来及组成
Kubernetes重要基础之命令模式和声明模式
Kubernetes的资源类型
京东智联云Kubernetes集群服务
在计算机技术日新月异、企业上云蔚然成风的今天，容器作为诞生于云计算时代的一种新技术理念，且作为云原生时代最小的颗粒和单元，经过长期实践已然被誉为云原生时代的一个核心基础设施。
Gartner还预计，2022年有75%的全球化企业将在生产中使用容器化的应用（当前约为30%）、50%的应用软件将容器化适应超融合环境（目前约为20%），容器地位由此可见一斑。
所谓“物有本末，事有终始，知所先后，则近道矣。”容器技术作为云平台的核心，要想更好的管理大规模容器应用，首先我们需要了解它的核心——容器编排工具。和其他任何组件一样，容器需要监控、控制，用户则需要一个编排框架来调度和管理容器。
Kubernetes作为大规模企业级应用容器编排的首推工具，其为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能。简单来说，Kubernetes让应用开发与交付更快速、最大程度上降低了用户的运维难度和复杂度、并且可以根据资源指标或应用指标自动扩缩容。
《解密京东618技术：重构多中心交易平台 11000个Docker支撑》
针对Kubernetes技术，京东智联云产品研发部专家架构师刘俊辉为大家分享了《六周玩转云原生》系列技术公开课第二讲，主题为《走近kubernetes，从概念到基础应用》。
Kubernetes到底有哪些组成部分和资源类型？让我们一起来回顾一下当天的精华内容吧！
六周玩转云原生
走进Kubernetes：从概念到基础应用
— 京东智联云 刘俊辉—
01Kubernetes的由来及组成
Kubernetes来源于希腊语，翻译成中文，意思是“舵手”。众所周知，容器本身也是集装箱的意思，而轮船运输集装箱需要舵手来操作，所以也可以认为Kubernetes它本身定位于容器的一个调度者。不过我们也常常看到很多从业者将kubernetes叫做k8s，据说是因为Kubernetes这个单词太长，不容易记，而首字母和尾字母中间正好有8个字母，所以也就简写成了K8s。
但并非所有的应用都适合选择容器，开发者可以根据自己应用的特点和需求选择最适合的计算单元。例如，你的应用是高性能、互信的，且处于同一个管理区域，那么用线程或者进程就可以满足；但如果你的应用是多租户的，并且和其他应用运行在同一个空间，那么你就需要考虑如何将这些应用安全地隔离开，使得数据不会被泄露或性能受到影响。那么这时，容器也许就是一个不错的选择了。
但是如果你想进一步了解K8s，首先要理解几个相关的概念，即集群、node和master。
- 集群K8s
跟docker不太一样的地方在于它侧重容器管理，因为它要面对的是一个比较大规模的、多节点的集群，所以它采取了把管理任务单独提取出来的方式，一个Kubernetes集群会有一个或者多个管理节点。通常来说，在生产环境上，K8s会有3-5个管理节点，这样当一个管理节点出故障时，可以保证集群仍然可以正常运行。当然，和docker类似，K8s也有一个client，就是客户端，用来操作并管理节点，同时和集群打交道，这个客户端就叫kubectl。
- master
Master是Kubernetes集群管理中心，每个Kubernetes集群里需要有Master节点来负责整个集群的管理和控制，它来负责接收和执行用户发起的所有的K8s控制命令。
在Master节点上有一个叫ETCD的数据库——一个分布式的KV数据库，这个数据库实际上也是第三方提供的，但是Kubernetes和它强绑定，顾名思义，就是说它不会用其他KV数据库，只用ETCD。这个数据库它保存了这个集群当前运行的工作负载的信息，可谓唯一信息中心，或者叫“single source of truth”，即所有的数据来源、信息来源都来自这个数据库，当我们对Kubernetes集群进行操作的时候，它做的第一步就是更新这个数据库，然后其他的人都围绕着这个数据库的信息开展工作。
Master节点通常会占据几个独立的服务器，归根结底是因为它真的至关重要，是整个集群的“首脑”，如果宕机或者不可用，那么对集群内容器应用的管理都将失效。而kube-apiserver却是Kubernetes里控制平面最最重要的一个东西，它是Kubernetes的控制入口 。
上面提到的kubectl客户端，和kube-apiserver通信，通信的方式基于REST API——定义得相当清晰完整的API。只要有了API，就可以和Kubernetes集群打交道。
- node
除了Master，Kubernetes集群中的其他服务器被称为Node节点，它是Kubernetes集群中的工作负载节点，也是容器应用实际运行的地方。每个Node都会被Master分配一些工作负载（通常是Docker容器），当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上去。
如图所示，node节点还要受master节点控制，究竟是如何操作的呢？其实它有一个叫做kubelet的后门，kubelet在每个node上都有一个，它是一个服务，并且只和master通信，而kubelet之间并不会通信
02 Kubernetes重要基础之命令模式和声明模式
Kubernetes实际上也可以运行容器，如下图所示，通过命令行就可以运行helloworld，和用docker运行的容器没有任何区别。
但并不建议这么做，为什么？在这里就不得不引入一个非常重要的概念，即命令模式和声明模式”。在此强调一下，命令模式和声明模式是Kubernetes的一个重要基础，只有先了解了它们之间的区别才能理解我们为什么要用声明的方式来创建资源。
举例来说，假设我们要完成一个任务，这个任务是要运行5个nginx副本，在命令模式下我们需要运行5次docker run，生成5个相同的副本，简言之，命令模式要求对方完全按照特定的指示来做，它自己没有有任何自主的想法。
而声明模式把以上所有步骤全部省掉，直接把需要做的事情在一个文件里声明，在文件里设置一个参数，最终运行5个Nginx副本。
那么问题来了，如果在运行这5个Nginx副本中间发生了错误，会出现什么样的情况呢？对于命令模式来说，会产生不可预期的后果 ，又或者需要额外的干预，比如之前的命令发生了错误 ，只运行了3个副本，我们必须要查看一下之前的命令是成功还是失败、有几个副本运行，如果之前运行了3个，那我们还需要再发出2次命令，运行2次。但是在声明模式下，我们把任务交代给谁，谁就负责来查看现在到底有几个副本，如果不是5个的话，它就会一直试图去恢复5个副本，直至成功。
那如果这个命令重复运行了2次，情况又如何？对于命令模式来说，如果运行2次，就会产生2倍的副本；而如果声明模式运行了2次，因为声明的是一件事情，除非第二次修改了命令，否则只要命令是一样的，那么就只会生成5个副本，这也是命令模式和声明模式最关键的区别所在。
命令模式要求我们交代操作步骤，而在声明模式只需要我们描述最终状态。 具体来说，在命令模式下，决策权掌握在发起命令的人手里，而在声明模式下，我们只需要把决策权下发给执行者，由执行者来关注如何运行、如何达到所需要的状态。
在故障处理方面，命令模式需要发起者处理所有的故障，所以它的复杂度是随着关注对象的多少呈指数增长的。而声明模式下，执行者只需要关注汇总状态，所以它的复杂度是线性的，维护成本相对命令来说要低得多。也因此声明模式更适合大规模应用，这也是Kubernetes使用声明模式的根源所在，即便它也支持命令模式。
03Kubernetes的资源类型
POD是Kubernetes最小工作单元，同时它也是一个独立的计算单元，它包含一个或多个容器。 对于Kubernetes来说，所有的资源都必须要声明它的API Version和它的资源类型，所以对于POD来说，资源类型就是POD，POD本身是单个副本。对单个副本来说，它的可靠性仅仅是当POD出现了故障，Kubernetes会试图重新启动它而已。也因为POD只是单个副本，所以它不支持版本升级，又或者它的版本升级只能是通过类似卸载重装的方式来实现，而这样显然会中断业务，所以POD是不能独立的用于生产环境的。
也因此，Kubernetes提供了另一种资源类型——deployment，又叫部署，它约等于多副本的POD，但同时比多副本的POD封装了更多功能。 Deployment集成了上线部署、滚动升级、创建副本、暂停上线任务，恢复上线任务，回滚到以前某一版本（成功/稳定）的Deployment等功能，在某种程度上，Deployment可以实现无人值守、无业务中断的上线，大大降低上线过程的复杂沟通、操作风险。
但多副本也面临这么一个问题：当我有多个副本的时候，如何确保这些副本有一个唯一的呈现、即有一个唯一的对外接口，这其实就是service需要完成的工作。Service是一个应用deployment加上对外暴露的网络访问接口，它有自己的资源类型。 Service在Kubernetes里边有3种类型：clusterIP、NodePort和LoadBalancer。
- clusterIP，是Service的IP地址，此为集群内部有效的虚拟IP地址。外部网络无法访问，只有kubernetes集群内部访问使用。
- NodePort，可以是物理机的IP，也可以是虚拟机IP，其实每个Service都会在Node节点上开通一个相同的端口，外部可以通过NodeIP:NodePort即可访问Service里的Pod，这就是提供service简单的对外访问的一种方式。
- LoadBalancer，它必须要和云平台做绑定。每个云平台会提供自己的LoadBalancer，而此时的LoadBalancer外部是可以访问的。
除了POD、deployment、Service，其实Kubernetes资源还有很多种，我们需要花更多的时间和精力去了解。不仅如此，所谓“纸上得来终觉浅，绝知此事要躬行”，我们更需要的是自己去搭建Kubernetes集群，这样才能对Kubernetes的内部工作原理有更深刻的认识。
04 京东智联云Kubernetes集群服务
显然易见，即便利用Kubernetes可以极大提高大规模容器集群管理的便捷性，但全面考量，本身的复杂程度非常高，用户熟悉起来非常困难。坦白来说，用户想要的是Kubernetes的能力，但不是特别愿意去运维、去管理这些节点，因为这不是用户的核心竞争力。
在京东智联云Kubernetes集群服务下，用户把管理任务完全交由京东智联云来负责部署和维护，自此不再需要关心这个事情。更便捷的是，用户可以根据自己的需要来选择工作节点组的类型。同时，我们将所有和云平台交互的插件集成好，并命名为“云操作系统的集成程序”，用户彻底解放双手。值得提及的是，这个集群服务通过了CNCF的兼容性认证。
不仅如此，针对K8s入门初学者来说，京东智联云还提供了控制台，用户在控制台上可以用图形化的方式来部署常用的资源和应用，真可谓一劳永逸。
Kubernetes已成为开发者、运维人员中最流行的开发工具，而在座的你又有什么理由out呢，正所谓“实践出真知”，快快行动起来吧！众所周知，Kubernetes + Docker 是 Dev 和 Ops 融合的一个桥梁。向大家详细介绍了Docker和Kubernetes的基本技术原理以及应用场景之后
《六周玩转云原生》的第三期课程将在本周三晚上8点进行，以《云原生下的DevOps与持续交付》为主题，对DevOps与持续交付的基础支持进行全面讲解👇👇👇
云原生的时代已来，而你，也将成为这个新时代的构建者之一！
转载：https://blog.csdn.net/jdcdev_/article/details/105240708