开发者学堂课程【Kubernetes 入门实战演练2020版：Kubernetes 简介】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/656/detail/10858
Kubernetes 简介
内容介绍
一、master 上的服务
二、k8s 组件介绍
三、node 节点上的服务
四、etcd
五、部署
一、master 上的服务
1.简介
上次简单介绍 Kubernetes 内部的逻辑图。
这个是 k8s master，master 通常是多节点图，这个图画的是单节点，多节点就是会有至少在两个或者三个这样的 master 来保证高可用，避免出现服务器不能用了，其中有一个 master 不能用而导致 k8s 不能用，不能通过 k8s 来创建容器映像容器，这样是不可以的，所以 master 一定是高可用的，用的一定是多节点，在最多的一个项目中一个k8s集群用了五个 master，通常是三个 master，有一个项目机器比较富裕，而且机器也可用，会把 master 跑一些别的服务，跑五个 master，这样可用性会更高，通常只要不出现五个 master 同时不好用的情况公司业务就不会中断，在此图基础上做k8s。
主要是在 k8smaster 上做相应的端口，此图里画了3个，master主要是实现容器的创建，调度和容器的生命周期的管理，容器的运行一般会让它运行在note那个节点，为什么会说一般呢，因为它其实也是一个服务器，在一定程度上它是可以运行企业里边的容器的，但是为了避免 master 因为运行容器而导致它产生一些CPU的性能负债比较高，或者说内存或者网络性能比较高，而导致在创建容器的调动上会出现延迟，所以说一般不让 master 跑容器，master 有三个组件，其中一个是Kube-controller-manager，一个是 Kube-scheduler，一个是 Kube-apiserver，Kube-apiserver是对外的，对外就是无论通过命令行通过待申报告，还是通过公司开发的自动化平台去调用k8s API，去创建容器也好，去做代码升级也好，都是先找到配套的k8s API，API接受你的请求之后，在我们内部进行调动。
内部调动就是如果你要创建容器的话，那么这个容器的创建会交给Kube-controller来控制，Kube-controller肯定是不知道要创建在哪个节点上，它会通过本地调动Kube-scheduler来看，Kube-scheduler会执行内部的一些筛选策略，这个筛选策略就是它基于目前能够知道的当前宿主机上的可用资源跟你筛选出来一个相对比较空闲的节点，然后让你把容器创建在这里，所以宿主机上每一个都有docker，这个上面就有一个一个的docker容器。
每一个node节点上都要装一个Kube-proxy和Kube-let，Kube-proxy主要是实现网络策略的管理，Kube-let是实现创建容器那些指定的下发，Kube-proxy和Kube-apiserver会进行交互。
2.k8s 核心优势
k8s的核心优势是基于yaml文件实现容器的自动创建和删除，包括代码升级，然后更快速的实现业务的弹性横向扩容，在上次讲过，如果现在一个服务器跑了三个容器，如果这三个容器在处理用户的处理用户的请求上性能不是很好，那可以很简单的扩充五个或者扩充三个，它会将所有的串联起来，所以一旦做代码升级，会产生一个峰值，这个峰值就是所有的宿主机都要到Huber去拉一下，导致Huber服务器网络连接比较高，不过这个是短时间的，只要把这项传输完就可以了，一个服务器只需要下载一次定向就可以了，而且不一定每个服务器都要下载，具体哪个服务器需要下载定向，需要看这个容器具体被创建在哪个节点上，被创建在哪个节点这个才需要拉进项目，才会下载定向。
还可以动态发现新扩容的容器，并对自动对用户提供访问，基于service标签自动识别到新加的容器，service adpoint中去也就是加到service后端服务器列表，这样访问时对用户是没有感应的，没有影响用户访问时通过访问墙访问公司容器服务，根本不知道你的容器做了扩容还是缩容，对于运营来讲也不需要配置负载均衡，所以说是全自动的。
最后一点是可以更简单、更快速的实现业务代码升级和回滚，做代码升级时在详细讲述。
二、k8s 组件介绍
1.Kube-apiserver
https://k8smeetup.github.io/docs/admin/kube-apiserver/这个是早期的文档，是v1.9版本不过apiserver功能是一样的，这个是新版本https://wWW.kubernetes.org.Cn/5482.html，这是k8s的中文社区，可以看中文文档。
1.pod
Kubernetes API server api 对象验证井配置数据，包括 pods 、 services 、replicationcontrolers和其它 api 对象。 AP Server 提供 REST 提作和到集群共享状态的前端，所有其他组件通过它进行交互。(对象在k8s中地位比较重要，要对哪些api进行调用，api 可以创建不同的资源，资源包括pods，pods就是k8s中的容器，以前没有讲k8s时一般说 k8s 容器是容器，但是实际上不是，因为是运行在一个一个pod，多个pod就是创建pods，k8s在运行容器时以pod为单位去运行容器的，也就是就算创建一个容器k8s在宿主机上拉开一个pod，pod在运行一个容器，一个 pod 中是可以运行多个容器的，后面在做pod时会讲示例，示例是在一个 pod 启两个容器，一个容器装 NDS，一个容器装PHP，而且他们有可能是不同的操作系统，一个容器系统是 Nginx，一个容器系统是sernos，PHP容器用无关图找，都可以实现，但是这两个都是在一个 pod 上也就是在一个地址其实是一样的，因为一个pod对外提供返还是一个整体，会提供相同的地址，但是文件系统是隔离开的，每一个容器都有自己的不同 OS 都有自己的文件系统，NDS使用的是 Nginx，ngnix 有自己的文件系统，PHP 用的是无关图的镜像，无关图有无关图的文件系统，但是他们网络是一样的，都会在 pod 内部封装一个接口，接口基于CNI的标准封装，网络接口可以使用 Frommer 来实现网络或者使用colarful来实现网络，这两个组件目前在公司应用比较多，他们都是符合 CNI 的标准，封装好接口后就可以从pod外部进行访问，假如都在k8s中都是通过 pod 地址访问的，那么别的pod就可以直接通过这个pod 的地址访问 NDS 访问 PHP，具体实现过程后续会详细讲解。
pods 是在 k8s 运行容器的最小单元，通常是这样理解的，就算只有一个容器会封装到 pod，因为 k8s 不单单是支持基于docker来创建容器，还支持基于pod或者是其他的容器基础例如push、rkt所以对于k8s讲，如果k8s想替换容器基础也就是cri，只需要将pod使用相关的容器技术封装即可，serviceks使用pod封装是将自己封装 pod 技术类似于做的更高级，可以调用底层的不同的CRI来实现自己pod的运行，不依赖于 docker 可以调用别的接口来实现容器的创建，通过别的方式来创建pod
pod翻译过来就是豌豆荚的意思，类似于花生，外面一个壳，里面有一个豆粒，容器类似于豌豆粒把容器封装到pod中，壳就是pod，豆粒就是一个一个的容器，一个pod中可以有很多个容器，具体有多少个要自己做，可以自己定义，只是在外层包了壳，让里面个个容器使用相同的外壳，外壳就是它的CRI，也会有CVI，因为在容器中数据不会做退化，所以数据一般会放到容器外层，放到容器外层会涉及到在容器怎样挂载到外层存储，这时也是通过pod进行封装，存储、网络都是通过CVI storage，想对容器的数据进行定义需要通过相关的接口调用容器外层的存储
2.service
将pod对外暴露的一种手段，如果pod需要外部的用户进行访问，有多种实践方式但是以一个pod好解决，因为不会涉及到将服务在多个pod之间进行调度，所以一个pod比较好处理，但是如果是多个pod同时运行一个服务如何让用户都能访问多个pod是一个难题，有两个NDS还有好几个harm cut。
先创建个 service，service 可以人工指定，手动去指定你要创建什么 service，在service 后端的 andpoint 那个 point 是谁自己去配，所以 service 就是 k8s 内部的一个负载均衡，用node point请求，service有自己对应的IP和端口，当然宿主机也有自己的地址和端口，这时可以去绑定，要把哪个service绑定到宿主机的哪个端口，那么一旦访问这个端口你的宿主机会把这个请求转化到相关service上，到了service ，service 根据它的 lab 标签创建出来后端的pod，把请求在转化过去，所以 service 实现了从宿主机外层访问k8s内部不同宿主机上多个容器的访问方式，而且不是简简单单的实现返还方式，还实现了pod的动态发现，新启的容器之后service有一个label筛选器，label会自动挑选符合事先制定好的筛选规则，把pod直接加到后端，一旦访问到这个service，service就会把相关的请求转化到pod当中去，因此可以说service是k8s内部的负载均衡器，这个service是手动去创建的，这个service不可以删除，在做代码升级时可以删pod但是不能删service，一旦将service删除，service相关的访问将全部被阻塞，一旦访问node port没有对应的service转化了，根本就访问不了，所以service不可以删除。
实验方式早期是用 iptables，在k8s1.11之后支持使用ipvs，ipvs性能会高一些，而且ipvs的算法比较高，比如菱形加长菱形可以去配，但是通常都是菱形的，因为pod的配置其实都是一样的，都依赖于宿主机的资源，所以对于pod来说没有办法指定相对来说比较固定，所以理论上每个pod的性能基本上差不多，主要因素是每个宿主机资源利用率比较高，pod 可能会受到影响，或者pod跑到node3上，但是node3上有其他的容器在处理一些比较大的请求，可能会消耗当前宿主机上一些比较高的资源，这个 pod 在这个宿主机上就有可能受到影响。
所以s ervice 主要是用来转化用户的请求到pod中。
3.replicationcontrolers
在新版本当中已经废弃，它是一个控制器，如果在公司用的是早期k8s版本有可能会用到这个控制器，专门用来控制 pod，现在使用 deployment，deployment 是replicationcontrolers 的一个升级版，deployment是目前主流的控制器，无论是deployment 还是 replicationcontrolers实践的目的都是一样的，就是保证 pod 的正常运行，通过基于检测机制，检测当前的 k8s 环境中 pod 是否运行正常，如果有pod所在的宿主机坏了，断电或者网线不好导致 pod 所有的容器无法正常运行，无法正常运行对于k8s来讲进行探测时就会发现这个容器状态异常，不是处于正常的运行状态而是处于一种退出或者error状态，一旦是退出或者error状态pod控制器就会对pod进行重建，重建会调用Kube scheduler然后再得出来目前相对比较空闲并且正常运行的节点，把这个损坏的node容器在其他节点上进行重建从而保证pod的正常运行，因为pod一旦被重建容积就起来了，容积一起来容器里的服务就起来了，所以要保证容积起来之后容器里面的服务会启动。
其它象后面进行讲解，象还有很多，例如账号的对象 account、存储的对象、PUC等等
Kubernetes API server api 对象验证井配置数据，这些数据无论是pods 、 services 、replicationcontrolers和其它 api 对象。，配置信息放在ETCD中，因为k8s控制端不存储任何数据，它的数据通通来源于ETCD，也就是无论有多少个master，master数据并不保存到任何一个master上，而是被班存到ETCD中，ETCD是一个集群不是单机，因为保证k8s数据的高可用，所以通过集群的方式来对于集体ETCD进行部署，正常它的性能以及增强数据的高可用，如果是集群换一个ETCD服务器是没有问题的，服务也不会有影响，如果要获取到数据，例如要创建容器，创建容器时会通过HAProxy进行转化，dashboard也会调用HAProxy，运维也会调用HAProxy，当然还包括自定义公司里开发的一些自动化平台，这些都会让他访问IP，通过IP来调用k8s管理端，所以可以把这个算法设置为文学访问master-1、访问master-2、访问master-3分别一次，访问master-1、master-2或master-3本质没有数据所以master的api Server 会链接ETCD，在访问给它的controller-manger或者scheduler，让controller-manger或者schedule来进行下一步的操作，比如Kube-scheduler进行筛选，筛选哪个节点比较空闲，Kube-controller根据筛选结果，把容器的创建指令进行下发，然后让相关的节点去创建容器，至于容器是如何创建的，它的流程是什么后面会讲解。
4.master这些组件作用
API server提供 REST 提作和到集群共享状态的前端，这个rest是API的一个方式，这种返回的数据或者提交的数据都是JSON格式，这是目前相对一种较流行的写法，或者是一种API比较流行的接口，可以通过API的方式基于delete或者get请求来进行增删改查，是开发中一种惯用的API方式，这个Kube-apiserver最主要的功能，提供时会加载一些参数，参数特别多，就不进行详细讲解了。大多数参数都是默认的，装完k8s不用更改，比如执行地址、鉴定端口保持默认就可以。
(二)Kube-scheduler
Kube-scheduler是一个拥有丰富策略，能够感知拓扑变化，支持特定负载的功能组件，它对集群的可用性，性能表现以及容量都影响巨大。
Scheduler需要考虑独立的和集群的资源需求，服务质量需求，硬件/软件/策略限制、亲和与反亲和规范数据位置，内部负载接口、截止时间等等，如有必要，特定的负载需求可以通过API暴露出来
(策略保持默认就可以，它有很多的策略，其中有一个比较通用的或者说能够适合大多数场景的，基于这个策略就可以，这个策略就是基于45级的硬件资源的空前，拓扑变化是这些k8s集群里会有很多的宿主机，如果这些宿主机加了节点Kube-scheduler会知道，因为Java节点数据会加到Kube-apiserver 里，Kube-apiserver这个数据不存在本地，会存储到ETCD，这个数据一旦存储到 ETCD，Kube-scheduler就能够通过Kube-apiserver拿到这些数据，就能够知道目前在k8s集群之内有多少个节点，然后每个节点的资源利用率都是怎么样的，因为在每个节点上装了一个另外组件叫做Kube-let，Kube-let 在其中会收集他的数据，收集数据然后返回到Kube-apiserver，Kube-apiserver 在将它写入到 ETCD 中去，所以k8s的管理端Kube-scheduler 就知道了当前k8s有多少个数据以及每个宿主机的资源都是多少，包括资源已用多少还有多少可用的，这个方式在 over sepen 也通用，只不过在over sepen要创建的是虚拟机。
在 k8s 中创建的是容器，over sepen创建虚拟机也要通过某个组件去收集未服务项的资源、CPU 和内存以及磁盘的空间，收集好以后返回给 over sepen 端，over sepen 只不过把数据集中到数据库而已，不是存到 ETCD 中，在创建虚拟机时over sepen 也有筛选器，结构和k8s基本是一样的，也会筛选目前未服务项目的可用资源，然后筛选出一台相对空闲等我机器创建下发到这个机器中，然后由这个机器执行虚拟机的创建，k8s也是这样进行加工的，所以这种信号和容器的管理master对于容器的创建和调度的操作很多地方都是相通的，因为需要再众多的节点中找到一个可用的主机，然后把这个操作下发到主机上让它去执行，所以他们有管理端和agent，agent对于k8s来说叫做Kube-let和Kube-proxy，不过Kube-proxy主要是用于维护网络的规则类型，Kube-let是和Kube-apiserver进行交互的，后面在配置文件中就能看到，Kube-let要指向Kube-apiserver，因为要去布置他怎么会知道他的master是谁，找不到它的领导就不知道自己的活怎么干，活是由领导分给他的，而不是它自己凭空想象出来的，所以容器的创建是统一的管理端去管理，而且数据是在共享的地方去保存，保证每一个管理端都能拿到一份相同的数据，也就是目前的容器一共有多少，每个容器的地址它的名称、在哪个节点去运行以及每个节点的资源利用率都会在ETCD中，会被每个master看到，所以能够感知拓扑变化，特定负载是创建某些容器时内部的算法可以把容器的创建分配到一些不同的节点上去，比如要创建一百个容器，不能都放在一个上，虽然说节点比较空闲，但这一百个容器肯定要分开创建，所以会创建到不同的节点上。
亲和是多个项目多个部门，部门之间硬件资源是独立的，比如两个项目两个部门他们之间有不同的leaderl，A项目是一个团队B项目是一个团队，这时a项目的硬件和b项目的硬件是不会在一起算的，在开发内部他们会有硬件的成本，在年底时会进行盘点，看点一下你这个项目花了多少投入，给公司带来了多少价值，A项目和b项目的硬件对于开发来讲是独立的，但是运维是一样的，运维不可能给每一个项目搭一个开发的k8s，或者说不能给每一个项目搭建一个open set，因为这样太浪费资源了，所以说在公司通常只有一套k8sOpen set，但是k8s或者一套OpenSet运行数百上千个虚拟机或容器，所以说所有开发的服务都跑到同一套管理k8s里面，那就是怎么能让指定项目的pod跑到指定的服务项，亲和性就是用来解决这个问题的，亲和性就是只把pod感兴趣的节点引领到相关的节点上去，会设立一个策略，这个策略是人工设定的，让pod运行在指定node节点上，意思就是让a项目运行在a项目的节点上，让b项目的pod运行在b项目的节点上，这就是亲和性，在一定程度上实现了pod和node的节点绑定功能，他会进行筛选，筛选是由Kube-scheduler来进行的，创建容器时会创建在指定的位置当中会附加一些策略，这个容器的创建有条件，条件就是只运行在Node上，node会进行分组，比如说group＝Linux 39，Linux 39就是这个项目，所以后面会给Linux 39这个服务器打这样一个标签，打完标签以后就把标签告诉 Linux39这个项目的pod，就找宿主机Linux 39这个标签带到node 节点，Node 的节点是由 Kube-scheduler筛选出来的，筛选出来以后Kube-scheduler 就会下发指令把 Linux39pod创建在节点，Note2和Note3里面是有Linux 39这个标签的，这个 pod 创建就会被分到这两个节点上，而不会被分到其他的节点上，这样就解决了 k8s 容器里的创建问题，这个功能在over sepen中同样有,over swpen也是这样操作的，创建虚拟机也是多个项目，多个项目，虚拟机肯定是不够用，所以k8s创建虚拟机也是，那就把a项目的虚拟机，比如说有数据库，有zookeeper，有其他的一些负载均衡等等，那么就把这些项目跑在他的虚拟机上，他的这个功能对于我来说很多都是一样的，只不过在实践起来会有一些差异而已，但是目的都是一样的，都是为了把这个容器或者虚拟机创建在不同的部门里面的机器上，都是为了这个功能。
反亲和是有些节点不执行什么功能，比如有些节点就不访问容器，所以在创建容器时，不创建在含有某些标签的节点上，这个就是在容器创建时发现含有某个标签的节点都不感兴趣或者都不在上面创建，这个反亲和用的不是很多，管理端才会用到，管理端是跑容器的，所以给master设置一个这样的标签，一旦有这样标签的节点就不在上面创建容器也就是告诉Kube-scheduler不要把容器创建在有这些标签的节点上。
亲和就是告诉Kube-scheduler我的节点就是要创建在哪些节点上，Kube-scheduler会给你调一些那些节点上比较空闲的节点上，所以亲和和反亲和在公司上运用是比较多的)
Kube-scheduler的参数也非常多，这个参数很多地方都保持默认，现在先不用管。
(三)Kube-controller-manger
作为集群内部的管理控制中心，负责k8s集群内的node、 pod副本、服务端点end point(其实就是port访问端口，port也是访问地址和端口的，这个端口其实是由Kube-controller-manger来负责的)、命名空间name space、服务账号Service account、资源定额resource quota的管理，当某个Node意外宕机时，controller manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。
pod副本
pod副本很重要，创建容器时通常不是一个，而是要创建多个，如果有创建多个那几个容器是否创建完了，例如，你要创建五个pod，这五个pod会通过Kube-apiserver进行创建，创建会通过Kube-scheduler进行筛选，筛选出来这些pod被创建哪些节点，然后Kube-controller-manger创建，创建时如果容器依赖的某些资源没有找到，这是很常见的，Kube-scheduler不负责容器的创建，只负责筛选，一旦筛选出来当前的节点上有符合前提的那些需求时，容器会指定占用多少内存，占用多少CPU，如果这些条件符合的话，Kube-scheduler调用功能就会完成了，完成之后就会把这个结果返回给Kube-controller-manager，Kube-Controller-Manager就会创建这个Pod，但是不一定会创建成功，因为创建时会挂载一些外部的数据，或者zookeeper或者资源数据库，这些功能Kube-scheduler是不符合的，因为他不知道你这个pod是不是能连接上数据库，到底能不能连上存储，到底能不能挂载存储，如果存储连接不上，或者说如果他依赖于某个外面的服务，只要外面的服务不同，还有可能导致容积起不来，这个pod就挂了。
例如我们学校他要它挂载外部的存储，这个存储他挂不上，因为这个地方需要授权，如果我们没有授权，那么在启动过程中挂载存储时因为权限拒绝，Pod就起不来，起不来Kube-controller-manager发现机器没起来，发现机器没起来之后会对他进行重建，如果连接不上，这个pod使用是创建不起来的，最终的解决办法是看报错，根据报错信息找出来是哪错了，把授权该授权的地方授权，该允许访问的地方允许访问，这个时候pod才能被创建上，但是Kube-controller-manager有一个比较主要的功能是刚才说要创建五个pod，他会帮你检查pod是不是创建了五个，如果不是五个，例如数量是三个，Kube-controller-manager会再创建直到pod数量等于五个，一个不多，一个不少，必须是完整的五个，如果多会删掉，少会重新创建，这个称为pod的副本数，其实就是他的数量
2.命名空间 NameSpace
命名空间在很多地方看到过，比如说在docker中，基于不同的命名空间来实现docker里面的各种资源隔离，在hammer中有project，Project是隔离不同镜像的，这个其实也是基于逻辑上的命名空间来隔离不同项目的镜像。
在k8s中也有这个概念，只不过在k8s中隔离的对象不一样而已，在k8s里是隔离容器的或者隔离pod。不同的namespace隔离不同业务的pod，例如多个项目，包括a项目和b项目，a项目的pod会让他跑在A项目的name space中，b项目的pod会让他跑在b项目的name space中，把他们在逻辑上隔离起来，虽然说他们都在一个k8s集群，但是他们是运行在不同的namespace之内的，在同一个name space之内他们是可以直接调用的，可以直接通过他的name space进行调用，如果跨name space调用需要写对方的name space的全称才能调用，因为这里面涉及到一个DNS的解析，在同一个name space之内访问比较简单，如果跨Name space需要写他的service全称，而且还可以设置网络策略，不允许别人访问我，不允许别人通过Name space访问，可以这样进行设置，但是这个网络限制一般用的不多
3.服务账号
服务账号其实也是k8sapi的一种，服务账号的创建，维护，删除，资源管理，资源管理比较重要，当创建pod时，也会分一些资源限制，而不会让他一直去占用，再讲docker时说过容器如果不加一些限制，容器会无上限的占用宿主机，包括Node创建，可以看一些node节点信息，node加进来之后就能在k8s中看到信息，这个也是由Kube-controller来负责的。
资源限定是创建一个容器，在之前讲docker时通过传参数的方式加一些CPU和内存限制，从而防止或限制这个东西可以占用当前45机上的资源，如果不进行限制，就会把当前宿主机的资源全部占完，他占完以后看起来对他是有好处，但是当前节点上的其他容积就是灾难性的，因为一个宿主机不止运行一个容器， 通常是几十个不会运行几百个，几百个要求的配置硬件非常高，普通公司买的宿主机通常是96G内存或者128G内存，如果是128G的话，运行一个harmCut需要3~4个g的内存，一个harm cut就是一个账户，128G也只能运行几十个，比如运行30个容器，如果其中一些容器不加限制，导致当前容器45G内存一直无限制占用，当然包括CPU，导致宿主机的资源利用率非常高，看CPU扩展或内存利用率都接近于百分之八九十，所以对于其他没有占用太多内存的容器，就是在灾难性的，因为这一个容器这一部分容器占用的资源比较高而导致其他这些容器都没有资源可用了，这是内核会出现OM，如果内核内存不够，会把内存占用较高的进程，在宿主机中也是个进程，会直接拿走，拿走以后Kube-controller一旦知道某个pod没了，数量不够了，假如跑了五个pod的其中一个宿主机扣走了，扣走以后，k8s Kube-controller还会在别的服务器重建，或者这个服务器重建都有可能，具体要看Kube-scheduler被调到了哪个节点上去，会反反复复把这个pod重建，充电还好，如果没有重建，这个pod把资源占用的比较高，还没有到被扣的触发地步，就会导致这些pod的资源比较少，比较少就会使处理能力比较低或者说性能受到影响，这个时候网站访问可能出现慢或者超时这种情况，所以基于这种场景要加资源限制，同样的道理也会限制CPU和内存，很简单，其实只有两个参数，只不过内存可以指定多少多少兆，例如限制成2g内存，可以写2048M，2048M是2G，CPU限制比较特殊，CPU限制在docker里面是可以限制1.几或2.几，在k8s中将CPU说成1000m，可以用千位制的方式去计算，一个CPU就是1000m，如果允许pod占用两个CPU的话，就是2000m，这是他对于node节点的管理，pod节点的管理还有服务端点的管理，命名空间管理就是创建name space，包括创建一些服务账号，服务账号是与权限相关的，k8s是支持多账号的，要登录k8s时有一个web界面，一个是web界面可以做认证，开发账号时不会开发一个超级管理员，怕把别的服务影响，管理员是对整个k8s都有完整的控制权限的，就是你想干什么就可以干什么，所以管理员权限比较大，为了安全考虑，不会给管理员，而是创建一些普通的号，而是让他只对某一个项目有权限就可以，例如a项目只能操作a项目，不能操作B项目，万一这两个项目属于竞争关系，A项目可以操作b项的，如果a项目直接把b项目删除了，虽然K8 s可以进行重建，但是也会对业务有影响，如果还做了其他事，重建不了，就会非常的麻烦。
还有其他账号内部进行调用时，有很多账户，有很多内部的service号，这些账号的创建也是由Kube-controller- manager来维护的。
上述讲的是master上的三个服务，这三个服务组成了一个完整的控制端，这个控制端只有Kube-apiserver才能对外访问，访问时访问的是Kube-apiserver，scheduler或者Manager是不能直接访问的，在外部是不能直接访问的，在本地可以，因为会有一个本地的安全接口后面会讲到。
三、node 节点上的服务
每个节点上都会安装Kube-controller-manager、Kube-scheduler、Kube-apiserver这三个组件，但是每个node的节点都要装docker，对于K8 s来说，有两个客户端组件一个是Kube-proxy，一个是Kubelet，这个是每个节点都有装的
1.Kube-proxy
Kubernetes 网络代理运行在 node 上，它反映了 node 上 Kubernetes API 中定义的服务，并可以通过一组后端进行简单的 TCP 、 UDP 流转发或循环模式（ round robin ))的 TCP 、 UDP 转发，用户必须使用 apiserver API 创建一个服务来配置代理，其实就是 kube －proxy 通过在主机上维护网络规则并执行连接转发来实现 Kubernetes 服务访问。
就是要创建一个service，Service是用户必须通过访问Kube-apiserver的方式，这个API有端口，端口默认为64443，需要访问server端口，通过端口来创建一个服务，这个服务就是service，其实不单单创建服务然后访问apiserver的api，所有的K8 s增删改查都需要访问server的API，所以，其实就是Kube-proxy通过在node节点上维护网络规则，实现用户访问请求的转发，其实就是转发给service，这时会做一个绑定将service端口需要管理员指定Service和Node port的对应关系，就是Kube-proxy在宿主机上打开一个node，这个node port就是service在宿主机上的一种体现，你想要访问service想要访问和他对应的nodeport，nodepod转化为service，service转换成后端的pod，通过leb标签来挑选他后端的port，通常都用tcp，不支持http等，基于tcp到serviceService转发到port上，然后到NDS容器，在Nds容器上在做HTC PS。
IPTables之前跑了几百个容器，每个Node的节点上IPtables大概有两三千个，两三千个都是少的，多的话会有三四千个IPtables，后期随着开发的升级因为IPtables规则会随着port数量增长而增长，IPtables数量太多会导致匹配速率下降，最重要把用户的请求一个一个与IPtables匹配，所以后面使用ls
2.Kubelet
是主要的节点代理，其实就是node节点上的代理，这个代理与网络没有关系，Kube-proxy只维护网络规则，Kubelet做的事比较多，主要是维护与容器运行相关的一些操作，Kubelet可见是已分配给节点的pod，每一个节点下都会有Kubelet，这个Kubelet只会管理它自己的容器，而不会管理别的节点上的容器，因为别的节点上的容器是他的Kubelet进行维护的，
具体功能如下:
①向master汇报node节点的状态信息(Kubelet在启动时会收集当前节点的硬件资源和一些资源使用指标，像这个指标汇报给master，汇报给master之后，master就拿到了当前节点的一些硬件信息，启动了多少Kubelet就意味着当前节点有几个node节点，有几个Node的节点在执行调度时可以根据Kubelet汇报的信息来进行筛选，打中需要创建的节点上)
②接受指令并在pod中创建docker容器(其实是接受Kube-apiserver下发的指令，其实容器的创建是由Kubelet来执行创建的，和open set一个意思只不过open set中容器的创建和他不同的是，open set 是nova来创建，Nova负责收集信息，在1
k8s中由Kubelet来完成，所以结构很类似)
③准备pod所需的数据卷(数据卷就是在创建容器时会产生一些数据目录，手机目录都是使用器的ID来命名的，是由Kubelet来完成的)
④返回pod的运行状态(返回这个是启动成功了还是失败了，失败是因为什么报错，会返回给Kube-apiserver，在创建完pod后可以检查)
⑤在node节点执行容器健康检查(如果容器挂了会返回给Kube-apiserver，返回给Kube-apiserver之后，apiserver就会把这个结果告诉给Kube-controller-manager说有的节点pod挂了，这时Kube-controller-manager就会进行验证，如果pod挂了，Manager就知道了，就会触发到策略，这列就重建维护一个我们预期的pod的副本数和状态，这个状态必须是running，如果状态不是running，这个Kube-controller-manager会对他进行重建，会一次一次重建)
这是node节点上的几个组件，其次就是ectd
四、ectd
1.简介
etcd是Kubernetes提供默认使用的key-value数据存储系统，保存所有集群数据，使用时需要为etcd数据提供备份计划。
K8 s所有集群数据无论是容器当中容器的名称还是node节点加到之后的那些Node信息都由ETCD来保存，ETCD支持分布式集群功能生产环境使用时需要为ETCD数据提供定期备份机制(创建一个集群来实现服务的高可用和数据的分布)
2.使用
etcd的使用比较简单，后面会详细介绍，这是etcd的一些基本介绍
五、部署
1.补充
以上是对于K8 s一些简单介绍，知道这些就可以进行部署了，目前最新是V1.18，1.18刚出来，除了刚才讲的这几个组件Kube-apiserver、etcd、Kube-scheduler、Kube-controller-manager、Kubelet、和Kubeproxy之外K8 s还有其他一些组件，这些组件通常以插件的形式存在，例如Addons，装网络组件，包括dashboard也是一个类似于组件包括监控，Kubemetes也是他的一个组件，所以他的生态主要包含这么几种，一种是管理端的服务，还有Node节点服务，以及一些其他组件，这些组件可以有选择的去使用在网站上或者很多组件，这些组件未必使用哪个，例如存储可以使用很多存储，网络可以使用好几种网络，具体使用哪个需要看公司具体或者说实际的场景，有些场景不适合某些组件的运行，但是有可能适合一些特定的组件。
2.部署
对于我们来讲，部署K8 s先规划一下服务器的节点，节点就是尽可能保证节点的够可用，但是要没有那么多机器一个节点也可以跑，这里会用三个节点，分别是master 123，机器已经准备好了所以不再重新创建，目前为止不要用rc的，因为rc已经被淘汰了，后期可能不再支持了，在1.8还是1.9的时候已经被development淘汰了，到现在已经更新十个版本了，最大的缺点是rc需要两个控制器来实现，Development 就一个。
IP 地址是172.31.3.101，部署之后就可以跑这个服务，就可以演示什么是rc什么是development 什么是 dashboard什么是网络组件，先把节点准备好，为了实现高可用可以使用负载均衡就是使用Hproxy来做高可用反应的代理，所以说负责均衡要准备两个，但这个不一定会用，这是把图给大家画出来，画出来的目的是大家都是公司之后可以按照这个方式去部署，如果机器不够可以跑一个，不用IP地址也可以，在公司用部署成高科用的方式，harbor用来保存镜像IP地址是172.31.3.106，还有Node的节点，这个Node的节点就是跑容积的地方，在实际的场景中，node节点往往是最多的而且配置普遍会比较高，node这点可能会是96G或者128G内存的服务器，控制端会稍微低一点，控制端如果是自己测试可以是2g内存左右就可以跑起来，ha-1少一点就可以，harbor要多一点，Node的节点也要稍微多一点，因为Node 的节点上会在上面跑很多很多的容器，所以在Node的节点上的资源消耗会更多一些。
目前官方版本最新的是1.18，1.18版本是昨天刚出来的，1.1 7.4是12天前出来的，1.1 6.8是14天出来的，他的更新特别快，而且到了1.16之后，K8 s中api版本发生了一些变化，之前那些文件大部分不能用都得改，也就是升级了现在版本之后，不但很多功能在使用上都有一些差异，但是他的升级会带来很多新功能，一些新功能能以及一些bug的修复，1.16和1.17功能差别不是很大，但是1.16和1.15的功能差别非常大，而且K8 s更新特别快，今年更新了三个版本所以在公司用有的公司可能在一年之前或者两年之前部署的，会稍微旧一点。
这里有之前一些跑的早期的VM文件版本，这个vm文件版本从K8 s1.8到1.15都是可以用的，但是从1.17就不能用了。
如果给大家讲1.15的，公司要用比较新的版本因为k8s更新较快，如果后期1.15有bug还要升级，升级以后发现这些文件全找不到了那就很麻烦了，这些文件在1.16之后不能用了，因为api做了更改，要改成当前API的版本。
