1 Kubernetes快速入门

了解Kubernetes

Kubernetes - 舵手

Kubernetes这个名字源于古希腊，是舵手的意思，所以说它的即像一张渔网又像一个罗盘。google选择这样一个名字还有一层深意，既然Docker把自己比作一只鲸鱼拖着集装箱在大海中遨游，google就要用kubernetes去掌握鲸鱼的航程，去捕获和指引这条鲸鱼按照主人设定的路线去迅游。

Kubernetes是什么？

了解了的名字含义，我们再从技术层面看看它是什么。

Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications.

上面是官网首页对Kubernetes的介绍，首先Kubernetes是一个Open source system， 为了自动化，什么自动化呢？让我们的应用部署实现自动化，还有管理容器化应用，这些就是它的核心目标。
Kubernetes是建立在google15年的生产环境的经验积累，经过大量的实践验证过的，并且融合了社区优秀的idea和社区的实践经验。可能会疑惑，Kubernetes才出来没有几年，为什么会有15年的经验积累呢？15年的经验积累其实并不是来自于kubernetes，而是来自于Google自己捣鼓了十多年的Borg系统，Borg是google内部使用的十多年大规模容器的管理系统，是他们经验的结晶。

Kubernetes主要特征

• 以服务为中心
  一切围绕着服务转，使用者不用去关心服务运行的环境、运行的细节，所以说构建在Kubernetes上的系统不仅可以运行在物理机、虚拟机、私有云、公有云，在什么地方运行都是无差别的
• 自动化
  在Kubernetes的服务可以自动扩充自动升级自动更新部署，比如Kubernetes在收到一个相应的指令后，它会触发一个调度流程，选中目标节点，部署或者是停止这样的服务。如果有一个pod重启，它会自动的加入负载均衡器自动的生效。另外，在服务运行的过程中，Kubernetes会定期的去检查实例数目，以及这些实例的状态是否正常，当发现某个实例不可用的时候，它会自动的销毁不可用的实例，然后重新去调度一个新的实例i。这些过程都是不需要人工过多的参与，全部是自动化完成的。

Kubernetes VS Docker

Kubernetes其实是可以看成Docker的上层架构，就像是Java和Java EE的关系，Kubernetes是以Docker为基础，准确的说是以Docker技术的标准为基础去打造一个全新的分布式架构系统。
当然，Kubernetes并不是一定要依赖Docker，Docker是一个产品，Docker技术本质是一系列标准，所以说只要实现了这个标准的产品都可以替代Docker，所以Kubernetes可以支持它自己的容器技术，并且经过了google的持续优化，在某些方面做的比Docker更加的优秀，用不用Docker我们也可以自己选择。

核心概念

K8s的架构设计还是有些复杂的，它里面有很多的概念。所以在了解k8s的架构之前，我们需要熟悉一下k8s相关的各种概念：

Container

每个Container都是由一个镜像起来的，比如上图镜像是login-image:v1

POD

容器外面的一层，POD里面可以有一个或者多个容器。POD有什么样的一些特征呢？

1. 首先它里面所有的容器都是运行在一台机器上；
2. 其次里面的容器共享网络，有一个唯一的IP；
3. 还有就是每个POD里面都会有个容器叫PAUSE容器，这个容器非常简单，一般会有一个特定的镜象，比如s上图叫pause:v1.0，这个Pause容器的作用就是使其作为跟容器，把其他的容器都给link到一起；除此以外，Pauser容器还有另外一个功能，它会负责整个POD的健康检查，然后汇报给k8s。当我们业务里有两个容器或者多个容器的关系非常紧密，这个时候呢我们就可以考虑把它们放在同一个POD里

ReplicaSet(RS)

POD的上一层叫副本集。同一个应用下，我们要运行几个实例呢？它就是负责管这个的。比如说同一个应用我们要运行两个POD，同样的它就会在运行起一个POD来，这个是和上一个POD是一模一样的，它就会把这两个POD管理起来，如果这两个POD有什么异常或异常退出，这个RS就会保证这个副本始终为2，在另一台机器去重新调度起一个。

Deployment

位于RS的上一层，是一个部署。我们想象一下这个场景，当你有一个旧的应用运行了两个实例，这个时候我想更新这个应用会发生什么呢？
我们更新这个应用的时候，一般就是更新的这个Deployment。它会自动的帮我们再创建一个RS副本集，并且它会滚动的先启动一个新版本的POD（如下图）

新的启动完成，并经过健康检查后，它会控制这个旧的RS把一个POD给删除，然后就是一个新版本一个旧版本，如下图：

旧版本下掉一个POD后，它会再创建一个新版本的POD，如下图

新版本的POD起来通过健康检查后，它会把前面的RS把它的另外一个POD也给停掉

整个的服务更新的过程就完成了，这就是一个典型的滚动部署的过程。其实在我们真正使用的时候，这个RS中POD创建和删除呢都是不需要我们去管理的，我们管理的层面呢只是在这个Deployment，Deploayment它会自动的帮我们创建和销毁RS，以及POD的这个此消彼长的过程。

Service、Label

Service是k8s中一个重要的概念，要想了解Service，我们需要先看下label。 label是标签，是k8s中非常非常多的一个东西，它的很多主键呢都可以进行打标签起到一个标识作用，Deployment、RS、POD都可以打标签，有时候运行了一个单点登录的服务也可以打标签。如下图：

一个Service的Selector中app=login，表示这个Service负责管理的这个样的标签‘app=login’，它就会自动找到打label两个POD。Service对外会有一个ClusterIP ，然后我们其他的服务如客户端就可以通过ClusterIP来访问到这个Service。

架构设计

Master 、Worker

我们k8s肯定是要很多的服务器很多的节点，这些服务器主要分为两种角色，一种叫Master，比如说它是一个主节点的机器。还有一种角色叫做Workder节点，worker节点呢可以有很多很多，它是负责运行我们服务的节点，Master节点就负责管理这些节点，如下图：

ETCD

我们知道一般的应用呢都有它的存储，有的是文件存储呀，有的是数据库呀，还有一些是存储的中间件呀，k8s也是需要自己的存储的，因为它要去管理我们的机器节点，管理我们的服务，这些信息可定是要放在一个地方的，如果不进行持久化的话，那么出现什么问题导致机器的重启，这样的话数据就丢失了就会导致我们的服务没有办法恢复了。k8s选择的存储的组件呢是ETCD ，如下图：

ApiServer、Scheduler

我们是如何访问这个集群呢？比如我要创建一个服务，是不是需要跟这个k8s集群做一个交互呀，这个时候Kubernetes中间Master节点上有个服务叫做ApiServer，这个就是用来操作k8s的对外唯一入口，提供基于http或https的api，当我们的apiServer接到了客户端的请求后，比如是一个创建Deployment的请求，它是不是要选择一个节点来运行POD呢？怎么来选择呢？这就用到了我们k8s的组件Scheduler，调度器它会收集每个worker的详细信息，包括他们的资源呀内存呀CPU呀节点上运行了什么服务呀等等各种信息，然后它会通过一些利的算法生成策略，主要有两大类：一个是预选策略另一个是优选策略，最终我们会选择最优的节点，然后把节点呢跟POD建立起一个关系，告诉apiServer 这个POD可以运行在这个节点上，ApiServer就会把这个消息存在ETCD里面做一个持久化。如下图：

ControllerManager

POD跟NODE之间的关系做了绑定之后，接下来就要真正的把一个POD启动起来了，这就用来到了ControllerManager模块，它是集群内部的控制中心，负责维护这个各种的k8s对象，比如说有ServiceController去管理服务，PODController去管理服务列表，ReplicationController是管理副本的，ResourceController去管理资源的配额的。它会时刻去关注这些内容的状态，并且时刻保证他们处于一个正确的状态。如下图：

上图中ControllerManager会通过ApiServer获取一些ETCD几点的变化，比如说刚才POD跟节点的绑定关系这样的一个内容就会被ControllerManager 监听到，它会通过一些目录去发现这个POD当前处于等待调度的状态，它就会完成这个调度让POD运行起来

kubelet

接下来的问题是我们的POD怎么在这个Worker上运行起来的，这就需要我们事先在每一个Worker节点上 去装好一个kubelet服务，这个服务会在每一个worker节点上都存在，它主要负责维护这个POD的生命周期，包括它的这个容器的网络等的管理。这中kubelet会调用本机的Docker去实现运行起容器，然后运行起我们一个个的POD，如下图：

上面讲的就是Kubernetes最最核心的一个架构，和有些主要的流程。

认证与授权

大家都知道，原生的Kubernetes环境的搭建非常的麻烦非常的复杂，为什么会这么复杂呢？其实有一半的原因要归功于它的认证和授权的机制，不但操作麻烦，理解起来也一样非常的麻烦，所以我们必须要把这这两个问题搞清楚，以免对我们后面的学习造成一些认识上的困扰。
我们知道Kubernetes里所有的资源，都是通过ApiServer组件来实现的。所以集群里最关键的点就在这个apiServer ，在于如何实现客户端的身份以及随后通过apiServer去访问的一些权限的授权。
在这里的认证和授权需要分开来看

认证

什么是认证呢？比如你要找工作，你跟面试官说你毕业于清华大学，面试官可能会半信半疑，但是当你把学位证拿出来，啪放在桌子上这个面试官肯定就信了，所以说学位证就是对你的一种认证。
再比如说我们上网，现在大部分都Https协议，如果浏览器显示的Https是绿色的，就证明当前我访问的网站是正确的，是经过了认证的是可信的，这也是一种认证，是跟Kubernetes中的认证非常相似了

想理解认证，我们必须得知道认证解决的是什么样的问题，防止什么问题发生。是防止有人入侵你的集群把你的机器root了，还要保证你的集群安全吗？不是吧，因为机器已经root了，防不胜防了。
其实网络安全本身是为了解决某些假设成立的条件下，我们改如何防范的问题。比如说有个非常重要的问题，如下图：

就是有两个服务，服务A和服务B进行通信的时候，中间的网络是非常不安全的，不可信任的，可能会被第三方不法分子去把这个信息截获或者篡改，就是把这个信息完全经过了另外一个人的时候，你俩发信息都可以被他看到，如下图：

就像上学的时候，你给心仪的女孩传字条可能会被中间的这个同学偷看，甚至会帮你把内容改掉，比如你写的“我喜欢你”变成“我不喜欢你”，这个后果呢不堪设想。当然这种假设不是随便想出来的，而是从当前的这个网络技术和实际发生的问题总结出来的。怎么来解决这样的问题呢？不需要自己想办法，因为这是一个任何需要在网络上通信的服务它都需要面临的问题，所以肯定是已经被解决掉了，这里我们就一块去了解下业内是怎么样来解决类似于这种问题发生的。

首先我们要连接密码学的两个概念，一个叫做对称加密，另一个叫做非对称加密。

对称加密、非对称加密

对称加密

什么叫呢？比如你有个数据“小姐姐好可爱”，这个数据是一个保密的数据，你不想被任何人看到。然后你执行了一个对称加密，用了一个加密的秘钥（abd123iwe），加密之后这串数据可能就变成了一个外人看不出来的乱七八糟的乱码，这个时候我们的接收端用同样的秘钥去解密，然后解密出来的结果呢就是跟我们这个结果就是一样的了，这个过程就是对称加密的过程。如下图：

非对称加密

上面的明文是一样的“小姐姐好可爱”，然后我们用非对称加密的算法去进行加密，也是有一个秘钥，加成一个秘文，然后解密呢是非对称解密，这个时候秘钥是另外一个秘钥，最终解密出原文。这种感觉很奇怪，加密的时候甩一个秘钥，然后解密的时候用另外一个秘钥，像这种算法呢就是非对称加密，两个秘钥互为秘钥对，一个称作公钥（加密的一般称作公钥），另一个称作私钥（解密的称作私钥）。

SSL/TSL协议

了解了非对称和对称加密解密之后，我们再来看一个场景：在网络上有两个服务，Service A ，Service B，它们俩要通讯，中间的数据是保密的，不像让任何人知道的。

如上图，首先最简单的方式是，A和B间直接建立一个Socket发了一个“hello”，这种肯定是不行的，中间一旦被人截获这个Hello就知道它的内容了。

如上图，第二种方式，刚才我们讲过使用对称加密的方式。我用一个秘钥把“hello”给加密成了一段秘文，把它发给了B，但是网络是不安全的呀，中间可能会被中间的人拿到这个秘文，然后这个人一看是个秘文，它也不知道怎么解开，也不知道你的秘钥什么，没有办法去破解你的数据，然后这个秘文就发到ServiceB了，但是秘钥是什么呢？ServiceB也不知道，因为事先并没有告诉ServiceB，你用的秘钥是什么。怎么办呢？

你可能会说，ServiceA 先跟Service B打个电话，先把秘钥告诉它一下，然后再给它发送数据。如果这是两个人写信什么的还可以实现，但是互联网 这个时间里，成千上万个服务是不可能通过人工的方式去来互相的通知秘钥的，这种情况还有其他的办法吗？

Service A可不可以给Service B先把秘钥发送过去呢？然后Service B拿到秘钥后，然后再把秘文给发过去，这也是不行的吧，因为当你发送秘钥的时候，这个秘钥也可能被中间这个人截获掉，它拿到你的秘钥后，你再发送数据的时候，它就可以把这个数据解开，这也是不安全的。

如上图，有同学可能会想到，我们用非对称加密的方式可不可以，因为非对称加密的过程就是Service B公开了一个公钥pubKey，任何人都可以看到，黑客也可以看到，没关系ServiceA 还可以通过公钥对数据进行加密。Service A对数据加密后发送向Service B，中间也可能被截获，但是截获的是秘文不能解开，因为黑客没有私钥priKey，到了ServiceB之后，Service B就可以用自己的私钥去把这个数据解密了，这个数据就安全送到了。

这里还隐藏了一个问题，就是非对称加密的算法非常复杂，运行这个算法消耗不管是加密还是解密都非常大，如果是每次通讯都进行非对称加密，性能损耗是无法接受的，相比于非对称加密呢，对称加密的性能是非常高了，鉴于这种情况，我们可不可以把这两种算法结合在一起进行通讯呢？如下图：

sErviceA 我们给ServiceB 第一次发送的不是加密明文后的秘文，而是生成一个非常复杂的秘钥，然后我用这个公钥去加密我这个秘钥，把我这个秘钥变成秘文发给Service B，然后中间这个人看到的是秘文，这样新生成的对称加密秘钥就安全的送到了Service B，然后ServiceB通过自己的私钥就可以把我这个秘文解开，解开一看它收到的是一个对称加密的秘钥，它就知道了Service A要跟它进行对称加密的通讯，并且使用的就是刚才发送过来的秘钥。ServiceA在接下来发送“hello”的时候，就可以使用它发给SErvice B的秘钥（不需要ServiceB的公钥了）加密“hello”，使用的对称加密算法，将加密后的数据发送到SErvice B，Service B因为也拿到了这个秘钥，可以通过这个秘钥去解密出“hello”。
这样的话，在这一个会话中，Service A和Service B就可以通过对称加密的方式去进行通讯了，不管是性能还是安全性都得到了解决。这个过程其实就是大名鼎鼎的SSL/TSL协议。这两个协议没有听过没有关系，Https你肯定听过，Https其实底层就是通过这两个协议进行通讯的。

CA

SSL/TSL协议就完整了吗？有没有什么瑕疵呢？其实还有一个潜在的风险，其风险在哪里呢？

这个公钥ServcieB返回ServiceA的时候，可能会被中间的人拿到公钥，它接到了pubkey:123456，但是它发给ServiceA的是pubkey:654321，Service A拿着这个公钥去加密了自己的对称加密钥，然后传输的时候又被黑客拿到了，然后它就可以根据自己的私钥把数据解密出来了，这样你的数据就不安全了。虽然这个工作要复杂的多，黑客要截获Service B 发向Service A 的公钥，并且还要截获Servicer A发送出来的加密的数据，但是这种情况确实是有可能发生的。

现在是如何解决这个问题的呢？现在是用的是一个叫做CA的证书认证机构， 是一个中间商，是给所有人颁发证书的一个机构，所有正常的网站的证书都在这一个地方存储，然后当Service A去管Service B 拿公钥的时候，拿到了还要去问CA这个公钥还不是合法的，是不是可以信任，直接可以查询出来。它的规范、那个公司、所有人是谁各种各种的信息，在CA都是有备案的，CA告诉Service A 没有问题，然后Service A在拿这个公钥就可以确保公钥是正常的。如下图：

现在这个过程才完整了，大家现在是不是知道了在访问网站的时候地址栏开头会显示一个红色锁的警告了吧，说明使用的公钥不是CA认证过的，是自己生成的。

Kubernetes的认证

客户端证书认证(TLS 双向认证）

当我们使用kubectl访问apiServer的时候，ApiServer一般是我们集群的唯一入口，访问的第一步就是要去认证，ApiServer要知道访问我的人到底是谁，我要有一个认证，这kubectl一般使用的就是现在讲的这个客户端证书认证的方式去跟ApiServer认证。

kubectl访问ApiServer的时候，它要认证ApiServer的证书是不是合法的。同样你的kubectl去访问ApiServer的时候，同样ApiServer也要去验证我的客户端kubectl是不是一个合法的客户端。所以说它们之间的认证是一个双向认证。认证过程中，刚才是说的知识，Kubernetes需要做什么样的事情呢？

首先Kubernetes需要有个CA，是用来判断和保证每个证书的合法性的。Kubernetes用的不是我们现在网站用的公有的一个机构，Kubernetes用的相当于是自己的一个认证机构认证中心，它在自定义的CA里为每个组件颁发证书，可能包括给etcd、scheduler、controllerManager、ApiServer、kubectl各种组件，只要需要用到证书，就为它们颁发，然后kubectl去跟api打交道的时候，就可以把自己的证书发给它，然后ApiServer也会把自己的证书发给这个客户端，它俩之间互相验证对方的证书是否是CA所颁发的，如果是的话就是没有问题的，它们俩就可以进行通过认证加密的通讯了，这就是客户端证书认证。

BearerToken

这是一个比较简单的方式，也可以理解为有一个非常复杂的密码，预先定义在ApiServer里面，它把这个密码告诉指定的客户端，该客户端跟apiServer进行通讯的时候，就把这个BearerToken给它带上，ApiServer验证下没有问题就可以进行通讯了。我们在开发容器管理平台的时候，可以通过这种BearerToken这种简单的方式去访问ApiServer。

ServiceAccount

前两种认证方式都是在集群的外部去访问ApiServer的时候进行认证，ServiceAccount呢是用于我们在Kubernetes的内部运行的Pod、运行的容器，比如说容器要跟ApiServer打交道的时候，要使用的就是ServiceAccount的方式。ServiceAccunt它跟Kubernetes的其它资源都是类似的，完全会可以创建自己的ServiceAccount，主要包含了3个内容：

1. namespace（命名空间）
2. token（密码）
3. ca(用于验证apiServer的证书)
   ServiceAccount都会通过目录挂载的方式去挂载到POD文件系统里，应用就可以通过读取指定目录的文件去获取到这些信息，然后拿到这些信息后就可以跟ApiServer进行交互了。

授权

如果说认证是访问ApiServer的第一关，授权就是访问ApiServer的第二关。认证是认证了你的身份，身份没有问题，第二步就是要知道这个身份的人，能够干什么样的事情。
Kubernetes里面有一系列的鉴权的机制:

• ABAC 最早的
• WebHook
• RBAC 1.6开始引入的最新的一个授权策略

因为Kubernetes它的社区的投入和偏好相较于其它的两种授权机制而言，RBAC是更好的选择，我们在这里只需学习RBAC就足够了。
RBAC的全称叫做Role Based Access Control ，就是基于角色的访问控制，我们对这个都很熟悉，一般的权限系统都少不了这个。

一般的权限系统都有这样的一个结构，首先是有一个用户user，然后这个用户拥有什么样的角色，角色下面又包含了那些权限，这样的三层的一个结构。
具体的这个Role、Authority就因具体的设计因不同的系统而不同了。
接下来看Kubernetes是怎么设计它的权限系统的：

首先在这个user这一层面上它分了两种用户

• User 普通的用户，比如我们使用客户端kubectl访问的时候都归属于不同的用户
• ServiceAccount 专门用于在集群内部访问ApiServer的

然后，再看看权限这一层，大家知道Kubernetes里面有很多类型的对象，有很多类型的资源，比如说POD，deployment，Service，等等各种各样的资源，我们的权限是不是得考虑让它们区分开呀，什么样的资源是你可以访问的，什么样的资源是你不可以访问的，分为下面的维度

• Resource
• Verbs 对资源控制的方式，比如list列表、新增、删除，其实就是curd

最后，说说Role的设计

• name 名字
• resource 那些权限
• verbs 那些操作
  
  用户、角色有了，这个用户跟角色之间的关系，如果在数据库里设计肯定是要有一张关系表的，这个用户拥有那些角色，在Kubernetes中没有数据库，那就用另外一种资源来描述对应关系，叫做RoleBinding(角色的绑定)，很形象很简单很容易理解。

到这里，Kubernetes的授权能跑通吗？
Kubernetes里有个非常重要的概念namespace，它是用来对这个Kubernetes资源起到了一个隔离的作用。有一种情况，如果有一个人只能访问某一个或某几个命名空间下的资源，我们前的设计能满足需求吗？不能吧，因为我们现在的设计并没有包含namespace的任何东西，于是Kubernetes想到了一个办法——把角色放到了namespace下面。如下图

比如说有一个namespace叫Test，这个Role呢只属于Test，如果一个用户拥有了这个角色，就只能够拥有当前命名空间下的角色对应的权限，这样命名空间的问题就解决了。

当然，还有一种情况是跨namespace，比如一个人拥有所有的权限，Kubernetes又提出了另外一种角色，叫做ClusterRole(集群的角色)，对应的它也有个叫ClusterRoleBinding(集群的角色绑定)，这个集群的角色呢除了可以定义跟普通的角色一样的Resource、Verb以外呢，它还可以定义集群范围内的资源。

大家知道并不是所有资源都属于一个namespace，比如说node,nodes返回的集群的机器列表，node这个资源就不属于任何namespace，但是它也是一种资源，这种情况如果要给一个人给node的操作权限，就需要给它定义一个ClusterRole，把这个node的权限加到这个角色里，这样角色的控制就比较灵活了，可以满足各种各种的需求了。如果一个人需要某一个或某几个namespace下的权限内容，就可以给他定义对应的几个Role，再把他对应的RoleBinding关联起来。如果他对应集群的node访问权限，就可以给他定义一个clusterRole，在这个Role的Resource里面，可以给他指定资源，然后再给他建立一个rolebinding，绑定用户绑定到ClusterRole上，就可以访问集群范围内的Service和Pod了，不受这个命名空间的制约了。还有一点需要提一下，就是刚才说的user，所有的rolebinding呀、clusterRolebinding呀，都是同时支持user和ServiceAccount的，这两种用户在权限设置里面是对等的关系。

AdmisionControl(准入控制)

可以理解为一个个的小插件，一个个的小代码，它们之间独立存在， 并没有什么之间的联系，我们的请求会一个一个的从准入控制的代码段里面执行一遍，一个个的执行。

具体执行那一些以及执行的先后顺序，我们在配置apiServer的时候，去指定。做Java的同学可以理解为一个个的filter。Kubernetes提供的这个AdmisionControl大概有十几二十几种，简单提几个，让我们有个基本的认识

• AlwaysAdmit 总是允许所有的请求通过
• AlwaysDeny 用于测试，所有的请求都会拒绝掉
• ServiceAccount 授权的ServiceAccount完全不是一个概念，是把ServiceAccount提供了一些自动化，会辅助ServiceAccount做一些事情，比如说某些POD没有ServiceAccount，它会自动的添加一个当前命名空间默认的ServiceAccount，确保这个ServiceAccount在每个POD里都存在
• DenyEscolatingExec 这个插件用于拒绝所有的Exec和tech到我们的具有一些特权的POD上，用于限制登录到我们的容器里执行命令的一个安全层面的插件

集群搭建方案

我们对比下常见的安装方案

社区方案

社区的方案伴随着K8s的诞生就已经出现了，k8s大家最初接触的时候最初的印象就是上手比较困难，安装起来比较复杂。所以说，由于复杂性社区也出现了各种各样的安装方案，它们又什么样的特点呢？

• 杂乱
  非常的杂，非常的多，五花八门的，一些是个人做的方案，一些是一些小团队出的方案，有点方案是单机部署的，有的方案是部署集群的，还有一些是高可用的方案，还有一些是非高可用的方案，所以我们在选择的时候也不是特别I容易的去找到我们想要的这个方法。
• 不可靠
  一方面体现在虽然大部分的解决方案都号称简化，但其实它们并不简单，如果安装过程中出现任何的问题都是出于字面很难定位原因，非常的难以解决，如果对方案涉及到的技术（如Linux Shell）不是很懂 ，出现问题基本上是搞不定的。
• 升级难
  比如使用了一个方案，半年前是1.0版本，现在想升级到1.3，你可定还是用之前使用的那个方案，因为你比较熟悉了。但是很有可能你发现之前那个方案就停留在了1.0，不支持更高级版本的安装，所以你只能用另外的方式做了。

上面都是说的社区方案的缺点，那有什么优点呢？暂时还没有想到，就不说了。

kubeadm

是官方比较推荐的方案，它有什么特点呢？

• 优雅
  使用kubeadm去安装几乎所有的组件都是运行在容器中的，并且都是运行k8s的pod里面，这个是它非常优雅的一个地方
• 简单
  安装的过程非常的简单，配上一个配置文件，运行一个命令kubeadm-init,它几乎会帮你做所有的事情，过程还是非常简单的。
• 支持高可用
  它不但支持非高可用的集群安装，也支持高可用的集群安装
• 升级方便
  升级可以说是随时随地，只要你拿到了kubeadm的命令，肯定是可以难倒最新的k8s的集群，因为他是官方出的，肯定会跟k8s同步更新

上面说的都是优点，那缺点是什么呢？

• 不易维护
  当你对容器不太熟悉，或者是说对k8s机制不太熟悉的同学，维护你来是非常的困难的。像我们传统的一些运维，如果让它去运维Kubernetes的POD，他可定是很难上手的
• 文档不够细致
  如果你直接按照官方的文档去做，很多时候你可能会卡主，或者是出现什么问题，很有可能你不知道说的这一步是什么意思，或者说有一些变量不知道该如何去替换，并且有的时候文档里面会有一些错误。曾经1.1的文档中kubectl中的yum配置文件在的内容是有缺失的，就导致很多用户花费很长时间去解决这个问题

Binary

二进制的安装方案，官方的安装方案，有什么优点呢？

• 易于维护
  因为它所有的东西都是通过进程直接运行的，并且需要你一点一点去配置好，并且是手动去运行起来，这样的话你就会非常的清楚每个组件它是怎么来运行，有什么样的调用关系，非常易于去理解，就算不熟悉容器的同学也很快的就能上手。
• 灵活
  不管你搭建单机，还是高可用，都是你一个模块一个模块的去运行起来的，你想怎么配置就怎么配置，控制你来非常的灵活
• 升级方便
  这个跟Kubeadm是一样的，可以一点点去升级，不会对真个集群造成太大影响。

我们在来看看二进制按装还有什么确定呢？

• 没有文档
  在官方文档里找了很多地方，都没有发现关于二进制的安装和配置的一些文档。所以我们在其他地方去找一些资料。
• 安装复杂
  一方面原因跟没有文档肯定是有一定的关系，还有个重要的原因是每一个组件都需要我们自己去进行配置，包括哪些数字证书、认证授权CA都是需要我们一步步的生成。

方案的选择

上面是我们介绍的几种方案，其中社区的方案并不推荐大家使用，官方的方案有两种：kubeadm、Binary，这两个是各自有各自的优缺点，可以根据自己的情况去做一些选择。
目前生产环境中，据了解大部分的公司使用二进制的方式比较多的，不过前端时间kubeadm的安装方式也已经GA¹了，不知道会不会有些公司会尝试是不是使用这种方式。

---

1. General Availability,正式发布的版本，在国外都是用GA来说明release版本的 ↩︎