docker中19-k8s的示例分析-创新互联
这篇文章主要介绍docker中19-k8s的示例分析，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
Docker的第一类编排工具：
1） docker compose（docker原生）：只能对一个主机上的容器进行编排，无法编排多个主机上的容器；
2） docker swarm（docker原生）：可以对多个主机上的容器进行编排。
3） docker machine（docker原生）：可以将一个主机迅速初始化到docker swarm集群里。
以上三个称为docker三剑客。
Docker的第二类编排工具：
mesos：它不是docker的编排工具，而是资源分配工具。所以mesos必须要依赖于容器编排框架marathon。
Docker的第三类编排工具：
kubernetes(简称k8s)：这个容器编排工具占用了80%的市场份额。
有了容器和容器编排技术，对持续集成（CI）、持续交付Delivery（CD）和持续部署Deployment（CD）的需求变为可能，这也就是DevOps的理念。
注意：DevOps并不是一种技术，而是一种运动，一种文化。
k8s的介绍
k8s是2014年google对外开放的。
Borg是谷歌内部非常棒的容器编排工具，k8s就是站在Borg基础上开发出来的，所以k8s从一出世，就吸引了太多太多人的关注，直到今天为止，它也确实没有辜负人们的期望。
2017年是容器技术最辉煌的一年，AWS、微软的云技术、阿里云等云厂商开始对外宣布，他们支持k8s。
k8s的代码托管在github之上：https://github.com/kubernetes/kubernetes/releases
k8s的特性：
1）可以自动装箱，即可以自动完成容器的部署，而不影响可用性；
2）可以自我修复，如果容器崩溃了，可以1s内重新启动，有了k8s后，我们不再关注个体，而是关注群体，有一个个体坏了，把它干掉，换一个新的就行了；
3）可以自动实现水平扩展，一个容器不够，再启动一个就是了；
4）可以自动实现服务发现和负载均衡，也就是说可以自动发现每个微服务之间的关系，同时也可以自动对容器内多个服务做负载均衡；
5） 可以实现自动发布和回滚；
6） 可以实现密钥和配置管理,也就是说每个容器不是加载容器内的配置文件，而是加载远程服务器上（配置中心）的配置文件；
7）可以实现存储编排；
8）可以实现任务的批量处理执行。
k8s是一个有中心节点架构的集群，由master节点（至少三个）和nodes节点(运行容器的节点)组成。客户的启动容器等请求会先发给master节点，master节点有个调度器会分析node节点资源(cpu、内存)的可用状态，找到最佳适配的node来启动用户请求的容器。
master上的第一个组件叫调度器（Scheduler），它的工作原理有两步：第一步调度器先做预选，即先评估到底有多少个node是符合容器需求的；第二步调度器再做优选，即在符合的node中选择一个最佳的node来运行容器。
如果node宕机了，那么托管在node之上的所有容器也就不见了。此时k8s可以在其他节点上创建出来和宕机node上一模一样的容器。
另外，master上还有一个组件叫控制器，它会不停的Loop，用来周期性监控每个node的健康状态；控制器是有多个的（因为有至少三个master）。
再者，master上还有一个组件叫控制器管理器(Controller-Mnager)，控制器管理器用来监控着每个控制器的健康。
在k8s上运行的最小单元不是容器，而是pod。pod可以理解为容器外壳，pod里面装的就是放容器的。一个pod里面可以放多个容器，这些容器可以共享一个底层的网络名称空间、存储卷，这样一来，pod对外更像一个虚拟机。
一般说来，一个pod里只放一个容器；如果一个pod必须要放多个容器，那么里面有一个是主容器，其他都是辅助容器，辅助容器主要是为了辅助主容器的主程序的某些功能而设置的。
一个pod里面的所有容器只能运行在一个node上的。
pod是k8s调用的原子单元，是个逻辑概念。
最终用户无需再关注pod运行在哪个node之上，这也就是云的概念，也就是把很多的node做为一个资源池，来进行统一管理。
pod尽量由控制器管理，而不要手工管理。
pod可以分为两类：
a)自主式pod：即自我管理的pod。我们创建Pod，首先交给Apiserver，然后调度器调度给指定的node节点，。如果容器需要启动，由node上kubelet组件来完成；如果node发生故障，那么pod也就消失了。
b）控制器管理的Pod(建议创建这种Pod)：这种Pod是有生命周期的对象。由master上的调度器将pod调度至某node进行运行或者停止。pod控制器后很多种，最早的一种叫Replicaton Controller（副本控制器），意思是当我们启动一个pod时，如果这个pod不够了，会再启动一个，这叫副本。副本控制器就控制副本的数量，一旦副本少了，就会自动再加一个。如果副本多于定义的个数，会被停止。也就是副本必须精确符合人们定义的个数。副本个数至少要两个。如果一个pod副本所在node宕机了，那么会向ApiServer重新请求，Apiserver借助调度器，到新节点创建一个新pod。滚动更新：比如我有个1.0版本的镜像，现在又有个1.1版本的镜像，那么控制器管理的pod就会新启动一个1.1版本的Pod，然后删除1.0版本的pod，这叫滚动更新。同样，k8s也支持回滚更新。到了k8s新版本，又出现了Replica Set（副本集控制器），但是该控制器并不直接使用，而是使用一个声明更新的控制器Deployment，这个也是用的最多的。但是Deployment控制器只能管理那些无状态的应用。而有状态的应用是由Stateful Set控制器管理。对于Deployment控制器，它还支持二级控制器，叫HPA（horizontalPodAutoscaler），该控制器可以自动水平扩展pod，也就是当一个pod压力大时，HPA控制器会自动水平扩展加几个新的pod来分解压力，具体加几个，HPA会根据当前节点的cpu、内存负荷来计算，一旦访问量小了，HPA还会自动减少pod个数。如果我们想在一个Node上只运行一个副本，需要用DaemonSet控制器。如果需要运行作业（如备份，清理数据等），需要conjob控制器。以上所讲的都是pod的控制器，用来管理不同类型的pod。
为了实现给pod分组，可以给pod打上标签（Lablel），这样就可以进行分组了。
标签选择器（Lablel Selector）组件：是一个根据标签来过滤符合要求的资源机制。
客户端是通过service来找到pod的，service是通过pod的标签选择器来找到pod的。service只是一个iptables方式的net地址转换路由规则，不过到了k8s最新版本1.11，支持了ipvs方式的分发规则，支持各种调度算法，这也就实现了负载均衡。。装完k8s后，就需要创建一个DNS pod，这是因为service的名字需要DNS服务器来进行解析。这种pod是k8s的组成部分，被称为k8s基础架构的pod，也被称为k8s的附件，英文名叫AddOns。这种DNS是用来解析service名字的，而不是pod的，并且DNS名称解析是K8s自动维护的，不需要我们人工干预。
一句话，service里面的地址存在iptables net或者ipvs里面，service是用来调度流量的，而不会启动或者停止容器的。
然而，pod的启动或者关闭、创建等是由控制器来做的，比如我们想创建一个nginx pod，就先创建一个Nginx控制器，nginx控制器自动就会帮我们创建nginx pod；然后我们再创建一个nginx service，把nginx pod发布出去。
service有两种类型，一种是调度流量仅供k8s内部来使用，还有一种可以调度流量供k8s外部来使用。
上图中，我们应该明白了service是用来分发流量给pod的，控制器是用来创建、启动和停止pod的，标签选择器是service用来根据标签来识别每个pod的。
在k8s运行中，需要三种网络，第一种网络是需要各pod在一个网络中，而service在另外一个网络，即service的地址和pod的地址是不同网段的，pod的地址是配置在pod内部的网络名称空间，是可以ping通的，但service的地址虚拟的，是假地址，只存在于iptables 或者ipvs里面。另外node又存在另外一个网络，这样就有三种网络。所以外部先到达node网络，然后再到service网络，最后才到pod网络。
那么pod之间是怎么通信的呢。同一个pod内的多个容器间通过lo进行通信；各pod之间通过overlay network（叠加网络）进行通信，即使pod之间跨主机，通信也没问题；pod与service之间通过网关（也就是docker 零桥的地址）进行通信。
node上有个组件叫kube-proxy，它负责和ApiServer进行通信，kube-proxy一旦发现service背后的pod地址发生变化，kube-proxy就会把pod地址反映到iptables 或者ipvs中。所以service的管理是靠kube-proxy来实现的。
在master(注意，master是有多个的)上的数据并不存在master本地，而是存在共享存储DB中，这个共享DB叫etcd。etcd里面数据是以key-value形式存储的，集群中所有状态信息都在etcd中，所以ectd要做冗余，一般至少三个节点。etcd是通过https方式访问的。etcd有一个端口是用来集群内部通信，另外 一个端口用来对ApiServer通信。这样一来，etcd内部通讯需要点对点的专门证书，对ApiServer通信就要另外一套证书。另外，ApiServer向客户端提供服务，也需要另外一套证书。同样，ApiServer和node上的kubelet组件和kube-proxy组件通信也需要CA证书。所以做K8s的部署，需要建立5个CA，这也是最难的。
下面我们把k8s归类为以下三类节点：master、node（上面有pod）和ectd（存储集群状态信息），它们彼此之间都是由http或https进行通信的。我们知道网络也分为：pod网络，service网络和node网络。所以我们要构建出三类网络来，但是K8s自己不提供这三类网络，而是要依赖于第三方插件CNI。
k8s通过CNI（容器网络接口）插件体系接入网络。目前常见的CNI插件是flannel。其实网络只提供两个功能，一个是给pod、service等提供ip地址的功能，另外还需要网络能提供网络测试的功能，来隔离不同Pod之间的通信。
flannel插件只支持网络配置（供ip地址的功能），但不支持网络策略。
CNI里面的插件calico可以同时支持网络配置和网络策略，但是calico的部署和使用非常难。
于是，又有了第三个CNI插件canel，它用flannel提供网络配置，用calico提供网络策略。这些插件可以作为k8s之上的守护进程运行，也可以在k8s里面的容器运行。
名称空间，可以实现不同类pod运行在不同的名称空间中。比如可以把名称空间分为开发名称空间、生产名称空间等。这样通过网络策略来定义名称空间之间、同一个名称空间的pod之间的网络行为。
本小节总结：
1）master/node:
a)master上包含的组件：API Server，Scheduler（调度器），Controller-Manager（控制器管理器）
b)node上包含的组件：kubelet（用来和master通信的一个组件，并试图启动本node上的容器等工作；另外启动容器是由容器引擎来操作的，最流行的容器引擎是docker）、docker引擎（也可以用其他容器引擎）、kube-proxy（负责和ApiServer进行通信，kube-proxy一旦发现service背后的pod地址发生变化，kube-proxy就会把pod地址反映到iptables 或者ipvs中。所以service的管理是靠kube-proxy来实现的）
2）Pod：Lablel（标签,kv格式），Lablel Selector（标签选择器）
生产中k8s的最终架构图（PaaS）
以上是“docker中19-k8s的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注创新互联-成都网站建设公司行业资讯频道！
文章标题：docker中19-k8s的示例分析-创新互联
文章转载：http://azwzsj.com/article/pphhp.html
