目录
docker的编排工具
docker的第一类编排工具（docker三剑客）
- docker compose（docker原生）：只能对一个主机上的容器进行编排，无法编排多个主机上的容器
- docker swarm（docker原生）：可以对多个主机上的容器进行编排。
- docker machine（docker原生）：可以将一个主机迅速初始化到docker swarm集群里。
docker的第二类编排工具
- mesos：它不是docker的编排工具，而是资源分配工具。所以mesos必须要依赖与容器编排框架marathon
docker的第三类编排工具
- kubernets：简称k8s，这个容器编排工具占用了80%的市场份额。
有了容器和容器编排技术，对于持续集成（CI）、持续交付Delivery（CD）和持续部署Deployment（CD）的需求变为可能，这也就是devopos的理念。
k8s的介绍
- k8s是2014年google对外开放的，2015年7月正式发布，截至目前最稳定的版本是1.9
- k8s是基于Borg开发出来的，Borg是google内部非常好的容器编排工具。
- 2017年是容器技术最辉煌的一年，aws、微软、阿里云等技术厂商对外宣布支持k8s。
- k8s是google开源的一个容器编排引擎，它支持自动化部署、大规模伸缩、应用容器化管理。在生产环境中部署一个应用程序，通常要部署该应用的多个实例以便对应用请求进行负载均衡。
- 在k8s中，可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。
- k8s由Golang语言开发，具有轻量化、模块化、便携以及可扩展的特点。
- k8s的代码托管在github上：Releases · kubernetes/kubernetes · GitHub
- k8s是一个有中心节点的架构集群，由master节点（至少三个）和nodes节点（运行容器的节点）组成，客户的启动容器等请求会先发给master节点，master节点有个调度器会分析node节点资源（cpu、内存）的可用状态，找到最佳适配的node来启动用户请求的容器。
- master上的第一个组件叫作调度器（scheduler）
scheduler的工作原理：
第一步调度器先做预选，即先评估有多少个node符合容器需求；
第二步调度器再做优选，即在符合的node中选择一个最佳的node来运作容器。
如果node宕机了，那么托管在node之上的所有容器也就不见了，此时k8s可以在其他节点创建出来和宕机node上一模一样的容器
-
master上还有一个组件叫作控制器，它会不停的Loop，用来周期性监控每个node的健康状态，控制器是有多个的（因为至少有三个master）。
-
master上有一个组件叫作控制器管理器（Controller-Manager），用来监控每个控制器的健康。
k8s的特性
- 自动修复：在节点故障时重新启动失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检查失败的容器，并且在为准备好之前不会处理客户端的请求，确保线上服务不中断。
- 弹性伸缩：使用命令、UI或者基于CPU的使用自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小的成本运行服务。
- 自动部署和回滚：k8s采用滚动更新策略更新应用，一次更新一个Pod，而不是同时删除所有Pod，如果更新过程中出现问题，将回滚更改，确保升级不受影响业务。
- 服务发现和负载均衡：k8s为多个容器提供一个统一的访问入口（内部IP地址和一个DNS名称），并且负载均衡关联的所有容器，使得用户无需考虑IP问题。
- 机密和配置管理：管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据的安全性，并且可以将一些常用的配置存储在k8s中，方便应用程序使用。
- 存储编排：挂载外部存储系统，无论是来自本地存储，公有云（如AWS），还是网络存储（如NFS、GlusterFS、CEPH）都作为集群资源的一部分使用，极大地提高存储使用灵活性。
- 批处理：提供一次性任务，定时任务，满足批量数据处理和分析的场景。
pod的分类
pod的概念
- 在k8s上运行的最小单元不是容器，而是pod，pod可以理解为容器外壳，pod里面装的就是容器。
- 一个pod里面可以放多个容器，这些容器可以共享一个底层的网络名称空间、存储卷，这样pod对外更像一个虚拟机。
- 一般来说，一个pod里只放一个容器；如果一个pod必须要放多个容器，那么里面有一个是主容器，其他都是辅助容器，辅助容器主要是为了辅助主容器的主程序的某些功能而设置的
- 一个pod里面的所有容器只能运行在一个node上，最终用户无需再关注pod运行在哪个node之上。也就是把很多的node作为一个资源池，来进行统一管理。pod尽量有控制器管理，而不要手工管理。
自主式pod
- 自我管理的pod。
- 创建pod，首先交给ApiServer，然后调度器调度给指定的node节点。如果容器需要启动，由node上的kubelet组件来完成；如果node发送故障，那么pod也就消失了
控制器管理的pod
- 一般建议创建控制器管理的pod，这种pod是有生命周期的对象。
- 由master上的调度器将pod调度至某node进行运行或者停止，Replica Set（副本集控制器），但是该控制器并不直接使用，而是使用一个声明更新的控制器Deployment，这个也是应用最多的。
- Deployment控制器只能管理哪些无状态的应用；有状态的应用是由Stateful Set控制器管理。
- 对于Deployment控制器，它还支持二级控制器，叫HPA（horizontalPodAutoscaler），该控制器可以自动水平扩展pod，也就是当一个pod压力大时，HPA控制器会自动水平扩展加几个新的pod来分解压力，具体加几个，HPA会根据当前节点的cpu、内存负荷来计算，一旦访问量小了，HPA还会自动减少pod个数。
- 如果我们想在一个node上只运行一个副本，需要用DaemonSet控制器
- 如果需要运作作业（如备份、清理数据等），需要conjob控制器。
- 以上所讲的都是pod的控制器，用来管理不同类型的pod。
service
- 为了实现pod分组，可以给pod打上标签Lablel，这样就可以进行分组了
Lablel Selector（标签选择器）
- Lablel Selector组件：是一个根据标签来过滤符合要求的资源机制
- 客户端是通过service来找到pod的，service是通过pod标签选择器来找到pod的
- service只是一个iptables方式的net地址转换器路由规则，到了1.11版本，支持了ipvs方式的分发规则，支持各种调度算法，这也就实现了负载均衡，装完k8s，需要创建一个DNS pod，这是因为service的名字需要DNS服务器来解析，这种pod是k8s的组成部分，被称为k8s基础架构的pod，也被称为k8s的附件，英文名叫作AddOns。coredns
- 这种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中需要三种网络
1.需要各个pod在一个网络中
2.service在另外一个网络中，即service的地址和pod的地址是不同网段的，pod的地址是配置在pod内部的网络名称空间，是可以ping通的，但是service的地址是虚拟的，是假地址，只存在于iptables或者ipvs中。
3.node又存在于另外一个网络。
总结：所以外部先到达node网络，然后到达service网络，最后才到pod网络
通信
pod、service通信
- 同一个pod内的多个容器通过lo进行通信
- 各个pod之间通过overlay network（叠加网络）进行通信，即使pod之间跨主机，通信也没问题
- pod于service之间通过网关（也就是docker 0的地址）进行通信
1.node上有个组件叫kube-proxy，它负责和ApiServer进行通信，kube-proxy一旦发现service背后的pod地址发生变化，就会改变service在ipvs中的pod地址，所以service的管理是靠kube-proxy来实现的。
2.kubelet--node上用于和master通信的一个组件，试图启动node上的容器，启动容器是由容器引擎（docker）来操作
认证与存储
存储etcd
- 在master（有多个master）上的数据并不存储在master本地，而是存储在在共享数据库中，这个共享的数据库叫作etcd。
- etcd里面的数据库是以k-v形式存储的，集群中所有状态信息都在etcd中，所以要对etcd做冗余，一般是三个节点。
- etcd是通过https方式访问的
CA认证
- etcd有一个端口是用来集群内部通信的，另外一个端口用来对ApiServer通信。这样一来etcd内部通讯需要点对点的专门证书，对ApiServer通信就需要另外一套证书
- 此外ApiServer向客户端提供服务，也需要一套证书。同样，ApiServer和node上的kubelet组件和kube-proxy组件通信也需要CA证书
- 所以做k8s部署，需要建立5个CA
插件
- 我们把k8s归为三类节点：master、node（内部有pod）和etcd（存储集群状态信息），它们彼此之间通过http或者https进行通信。
- 网络分为：pod网络、service网络和node网络，所以需要构建三类网络，但是k8s自己不提供者三类网络，而是依赖于第三方插件CNI（flannel、calico、canal等等）
- k8s通过CNI（容器网络接口）插件体系接入网络，目前常见的CNI插件是flannel。
- 其实网络网络只提供两个功能，一个是给pod、service等提供IP地址的功能，另外还需要网络能提供网络测试的功能，来隔离不同的pod之间的通信。
- flannel插件支持网络配置（供IP地址功能），但不支持网络策略。
- CNI里面的插件calico可以同时支持网络配置和网络策略，但是calico的部署和使用非常难。
- CNI的第三个canel，它用flannel提供网络配置，用calico提供网络策略。这些插件可以作为k8s之上的守护进程运行，可以在k8s里面的容器运行
总结：
1.master上包含的组件：API Server、Scheduler（调度器）、Controller-Manager（控制器管理器）
2.node上包含的组件：kubelet（用来和master通信的一个组件，并且试图启动node上的容器等工作；另外启动容器是由容器引擎来操作的，最近流行的容器引擎是docker）、docker引擎（也可以用其他容器引擎）、kube-proxy（负责和ApiServer进行通信，kube-proxy一旦发现service背后的pod地址发生变化，kube-proxy就会把pod地址反映给iptables或者ipvs，所以service的管理就是靠kube-proxy实现的）
3.pod：Lablel（标签，k-v格式）、Lablel selector(标签选择器)
907
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
