**基于容器运行，或者基于微服务运行时，如果容器时分离的，有多个dockerhost，将来启动容器的时候，这个容器可能并不在当前主机上，一个业务中可能会包含很多容器，比如
NMT
nginx 高可用至少两个
tomcat 6个
mariadb 主从 3个
就需要11个容器，这些容器在创建时，谁先启动谁后启动，2.引用的时候该如何进行，，tomcat必须要引用到mariadb，mariadb对于的容器启动在不同的主机上，由于各容器，在跨dockerhost主机通信时，是nat方式进行的，对方的地址会随时发生改变，引用起来极为麻烦，就算nat做了端口暴露，后面的引用逻辑也会非常复杂
这么多容器谁先启动后启动，依赖关系的定义，如果被依赖的启动不了，都需要自己定义，如果手动管理将会极为麻烦
需要一个容器编排工具，docker有自己的解决方案
**
**docker容器编排三剑客，三个组件结合起来完成的
1.docker-machine 管理docker各节点的。docker主机
2.docker-swarm 管理容器集群的，能跨多个主机监控容器
3.docker-compose 编排，yml格式的文档
容器被docker-swarm统一调度监控，哪些docker主机配置集群由dcokermachine来配置管理，
如何保证编排有序启动，docker-compose **
后来又两个非常强大的编排工具
ASF旗下的 mesos 资源调度框架，编排容器需要依赖marathon，IDC操作系统，hadoop都能调度
google下的kubernetes，k8s
google内部已经有对应十几年的容器运行化经验了，IDC机房众多应用都是容器化的
一切皆容器
一周启动20亿个容器，所以google积累了非常多的容器使用经验
统一调度的框架是borg
**在borg的使用经验之上，引入另外一个产品，用kubernetes开源出来了
deployment部署
maintenance维护
scaling of application 应用程序伸缩，按需启动 **
三种解决方案
docker
ASF
google
1.5版本的提交已经达到37000此
https://github.com/kubernetes/kubernetes
kubernets是go语言研发，运行需要配置环境变量
https://kubernetes.io 官方站点
亚马逊的AWS 阿里云运行也是没什么问题的
laas，底层有paas
k8s会引入一堆的新概念，这种编排工具主要实现跨主机管理的，容器主机需要有多个，所以k8s本来就代表集群
k8s的集群架构是master，agent模型（node）
第一个节点是master，是调度的统一分配框架，提供API的监听，所有客户端的请求都是发给这个API（创建容器，删除容器，）都向master上的API接口发送请求
master收到请求以后还有另外的组件，Scheduler调度器，由调度器负责将用户，比如创建，找node主机，看看哪个比较空闲，将其作为调度的目标主机
由此主机在本机启动用于所需要启动的容器，包含创建
集群节点必须要连接到合适的registry，下载好合适的镜像到本地
对整个集群来讲，master到底运行了多少容器，每个容器有多少属性，运行在哪个主机上，这些信息，要找一个位置存储，放在一个强一致性，拥有容错能力的键值存储集群服务存储
这个键值存储能够多节点构建成集群，而且数据支持强一致特性，一个节点挂了并不会访问其他数据访问，master节点挂了，重启起来依然没什么问题，能够继续访问
如果某个node挂了，在master上还有一个组件，叫control manager控制管理器，监控你所部署的，每一个容器的数量是否够，每一个容器要求1个，如果检查发现挂掉了，再重新调度一个节点启动一个
比如tomcat服务启动三个容器，需要确保你有三个，多了杀掉，少了补全
受到请求，给
完成调度
etcd就是强一致的kv存储（raft协议，简单快速一致的，容易理解的，键值存储只是一个核心简单的功能）go语言，轻量高性能，非常相似zookeeper（用的协议是一种变化的paxos协议） java
整个kubernetes整体框架就是有一个master主机，master主机完成的任务，apiserver ，接收请求，完成请求，调度用户任务scheduler
任何状态是否满足 controller-manager，监控目标状态接口
node主机跑
1.kubelet 作为agent端进程，每个节点都需要运行，所有master发来的任务都是由kubelet执行的，包括启动容器
docker/rkt容器部署环境
kube-proxy代理对本节点上的服务的访问
cli命令行工具（著名工具kubectl），ui图形工具（dashboard），api程序接口
Kubernetes
架构：master/agent
master主机：
kube-apiserver
kube-scheduler
kube-controller-manager
agent主机（node）：
kubelet
container runtime(docker/rkt/…)
kube-proxy 接收用户请求发送到container上的代理，类似nginx，haproxy反代
这些就是kubernetes核心架构组件
各 node链接到Registry，下载镜像，运行容器
kubernetes master要能够输出API接口，让用户通过三种方式。API,UI,CLI的方式来链接调用服务
组成kubernetes
master的数据存储在etcd上
kubernetes三个核心组件+etcd（运行在其他主机上，本身也是个集群）
kubernetes的node节点
**对每个node节点，都需要要引入docker的运行环境
kubelet代理，agent
kube-proxy 服务访问的代理
1.pod是kubernetes的核心组件而不是容器
2.addons附件（插件可以理解为整个系统的功能之一，附件是有这个功，整个生态有整个功能，要用需要额外安装，并不是系统不可分割的一部分）dns是著名的附件，ui图形化接口，需要用就需要安装
3.fluentd日志收集工具，（logstash）
**
对整个kubernetes，pod是最为核心的组件，pod内部是用来跑容器的，pod是容器组，container group容器组，
在同一个pod的容器，共享同一个网络名称空间，所以是joined conatiner 联盟，（大家拥有同一个ip地址或者同一组网络接口，lo即可通信，）
pod特别像虚拟机。，
在docker中，每个容器是用来运行一个程序的，把多个容器和起来使用同一个ip地址，pod就非常像虚拟机，回到虚拟机的方式就是使用joined container ct
所以每一个pod都是联系比较紧密的容器，需要通过lo接口通信的，都放在同一个pod中，就表明地址属于pod而不属于容器的，pod自身如何拥有ip地址，它自己也需要作为一个容器才可以
pod是一个虚拟的概念，但是也需要一个容器来表示pod的基础架构，意味只要启动pod，在pod内部必须有一个容器，只不过这个容器一直处于pause状态，没有其他作用就是附加一个ip地址，任何后来启动这个pod中的容器就直接join到这个基础架构容器上来
可以把一组联系非常紧密的容器放在一起，一个nginx容器跑一个nginx，但是将来收集日志该怎么收集，（elk得需要跑一个beat来收集日志或者logstash）把日志放在卷上，多个容器跑在同一个pod中，共享一个ip地址，也是有同一个卷，nginx负责写，filebeat负责读，读出来，再送给elk或者redis
所以有时候需要多个应用程序跑在一起才能完成某个任务的，现在就需要把一个程序跑在紧密的组容器中，
所以kubernetest就造出的容器组件，pod，只有这么紧密的才需要跑到一个pod中
NT架构，nginx，tomcat不止一个，不能把tomcat放在一个pod中，如果放在pod中，就不能使用相同的端口了，就相当于再一个虚拟机上跑了多个tomcat实例，所以还需要把三个tomcat跑在三个pod中，每个tomcat应该还有filebeat 去收集日志
现在有三个pod都是tomcat的，加入前端有nginx，用户请求要调度到三个tomcat容器中，这三个tomcat容器分别跑在三个pod上，用户的请求需要从nginx的pod发送到三个tomcat的pod
如何去引用三个pod，容器都有生命周期，重启了ip地址会发生改变，所以不能用ip地址反代，每一个pod用dns解析其名字和IP地址对应关系，引用的时候引用名字，而不引用主机，
这种方式有一个问题，dns称为必须要配置的服务，还要确保每个pod都要实时访问，更重要的是，如果跨界点的话，这三个pod在不同的节点上，这样访问起来会更加麻烦，很难用一个名称引用，这时候可以这么解决问题：
ip地址是发生变化的，每创建一个pod就打一个标签，标签一般是kv组成，（k=app：v=tomcat），因此每一个tomcat的pod都打标签，第二个，第三个pod都有同一个标签，所以不管ip地址是什么，标签是它就可以引用，只要标签相同的就可以归集到组，每一个组取一个ip地址当作对外通信的地址，因为他们有可能运行在不同的主机之上，为了引用这些pod，不用ip地址来引用，而靠每创建一个pod来打一个标签label，把对应的几个标签收纳起来，把标签归集成组，给这个组取一个ip地址，
把标签里值相同的都归成group，给这个组取一个名或赋予一个ip地址，所以以后有人想要访问tomcat，只要访问这个地址即可，这个ip地址是固定的，
从这个角度来讲，一组pod所形成的组，赋予一个ip加上这一组所有的信息，归集起来，就叫做一个service，可以认为是个tomcat服务，请求这个服务不用向任何pod发送请求，这需要向这个service对外宣称的ip发请求，它自己的ip轮询到不同的pod上，所以称为服务service
对kubernetes来讲是重要组件
service如何定义，由一组容器+ip组成，必须把一组功能相同的pod归集成组，（如何知道功能相同）启动一个pod，给个键，这些键对应的pod值相同，挑选键以后确保值相同，的操作叫做select，服务的挑选器，
所以一组服务想通过的pod可以组成一个服务，统一颜色可以理解为label一样，由service自动归集成组，对外统一一个ip地址，所以service更像一个调度器，就是一个iptables规则
service是一个逻辑概念，任何概念都需要实现，把一组pod结合起来赋予一个ip地址以后，作为同一个ip地址来访问的，kube-proxy
service定义好了，展现出来的就是kube-proxy中的一个代理，这个代理就是一个负载均衡器
controler manager有三种实现方式，
rc replication controller
rs replication sets
每一个容器占了多少cpu，内存，io
cAdvisor各种资源使用和性能统计数据，每个容器只能运行一个程序，要收集这个容器的性能数据，不可能在容器里在运行程序了，只好再运行一个容器，这个容器就是帮你收集各个pod运行容器的性能数据和使用率数据，探测只需要向主机探测即可，主机内核肯定分了很多用户空间，向用户空间收集数据，就可以知道容器的使用情况
cAdvisor就是主机上的，各容器性能数据和使用率数据的统计代理程序，kubernetes自带组件
kubernetes调度也是以pod调度，而不是容器
同一个pod中的容器之间的通信靠IPC，进程间通信，共享内存，LO接口
pod的里的容器拥有同一个主机名
同一个pod里的各容器共享ip地址，网络名称空间
同一个pod内的各容器使用同一个卷
如何去部署一个pod
需要一个配置文件，来部署好要启动的内容
pod定义的文件 definition
replication controller 复制控制器，控制管理决定运行在哪个节点上
这些是rc replication controller实现方式
在一个node上有很多pod，颜色相同代表label的键值一样，可以把红色label的做成一个service，用户向service发请求，service合理调度到不同的pod上
紫色的lable在定义一个service，向它发请求，也合理调度到pod上
service可以想像成访问容器的统一接口，而且本身隐含调度功能，
label定义好以后，可以指明labels是哪一个，来定义出一个选择器，以便将多个pod归集成组。label就是附加在pod之上的 kv键值对
对kubernetes来讲，每一个对象都可以附加label，不光是pod
service就是一个静态API对象，固定ip地址，不再需要服务发现了，因为地址是固定的
一个service就是一个virtual ip，client向virtual ip发请求，分发到各pod上，
这个VIP是由kube-proxy来管理的，service只是一个逻辑概念，真正能去配置生成ip地址，而且用户请求合理调度到pod上的，是kube-proxy，
如果proxy一变，vip地址就改变了，kube-proxy要负责监视所有的服务，以确保服务对应的pod，变化时要立即更新，对应的规则，kube-proxy其实就是靠iptables规则来实现的
proxy模式由两种
1.在userspace中
还有一种是在主机上实现iptables规则
在k8s的中，服务发现
一种使用环境变量，一种使用dns
dns是一个非常核心的附件，1.3实现的时候交skydns，1，3以后附件叫kubedns，这个附件基本上要安装kubernetes以后要安装生成的，gcr。io
需要自己编辑分配才能安装
每一个主机上都有可能被master上 的Scheduler调度器，调度运行很多pod，pod一旦被调度完以后，pod是不是够数，需要找controller-manager来确保
Scheduler调度哪个节点，controller-manager确保是否够数，不够数再想master请求不够的数量，Scheduler再次调度到合理的节点上
而到底创建哪些各pod是靠用户通过api来发请求来决定，不是集群自己决定的，运行以后，都表现为一个个pod
（比如由 三个pod，在第一个节点有两个，在第二个节点有一个，假如下面的挂掉了，如果数量不够了controller-manager就向apiserver发请求，apiserver给Scheduler发请求，在启动一个pod，所以就有可能后来变成第一个节点一个，第二个节点两个，地址会经常发生变化
pod很多，nginxpod要运行，tomcatpod要运行，由调度器根据算法来决定，哪个调度到哪些节点，哪个运行哪些pod
划分成组，把pod固定在一起，给pod设定label，通过标签相同的方式，定义成组，标签相同的组，定义出的组件叫服务，service，服务有一个固定的ip地址，在每一个主机上都应该有一个服务进程，叫kube-proxy，
等于配置一个静态ip地址，节点有多各，每个节点都有可能作为访问入口的，给网卡配置一个静态的ip地址，可以这么想象，但是不需要这么配置，目标只要是这个ip地址的，在当前节点上有几个与之匹配的pod，就调度过来，如果不在这个节点上就转发给合理的节点，
kube-proxy定义的规则将一组服务器，定义成service
就算不是外部用户调用，给nginx反代逻辑也一样，所有用户请求直接发给nginx，nginx地址会变，定义一个服务，叫nginx，定义到nginx的服务，设定为静态地址，这个服务由kube-proxy负载监听这个静态地址的访问，对用户
**基于容器运行，或者基于微服务运行时，如果容器时分离的，有多个dockerhost，将来启动容器的时候，这个容器可能并不在当前主机上，一个业务中可能会包含很多容器，比如
NMT
nginx 高可用至少两个
tomcat 6个
mariadb 主从 3个
就需要11个容器，这些容器在创建时，谁先启动谁后启动，2.引用的时候该如何进行，，tomcat必须要引用到mariadb，mariadb对于的容器启动在不同的主机上，由于各容器，在跨dockerhost主机通信时，是nat方式进行的，对方的地址会随时发生改变，引用起来极为麻烦，就算nat做了端口暴露，后面的引用逻辑也会非常复杂
这么多容器谁先启动后启动，依赖关系的定义，如果被依赖的启动不了，都需要自己定义，如果手动管理将会极为麻烦
需要一个容器编排工具，docker有自己的解决方案
**
**docker容器编排三剑客，三个组件结合起来完成的
1.docker-machine 管理docker各节点的。docker主机
2.docker-swarm 管理容器集群的，能跨多个主机监控容器
3.docker-compose 编排，yml格式的文档
容器被docker-swarm统一调度监控，哪些docker主机配置集群由dcokermachine来配置管理，
如何保证编排有序启动，docker-compose **
后来又两个非常强大的编排工具
ASF旗下的 mesos 资源调度框架，编排容器需要依赖marathon，IDC操作系统，hadoop都能调度
google下的kubernetes，k8s
google内部已经有对应十几年的容器运行化经验了，IDC机房众多应用都是容器化的
一切皆容器
一周启动20亿个容器，所以google积累了非常多的容器使用经验
统一调度的框架是borg
**在borg的使用经验之上，引入另外一个产品，用kubernetes开源出来了
deployment部署
maintenance维护
scaling of application 应用程序伸缩，按需启动 **
三种解决方案
docker
ASF
google
1.5版本的提交已经达到37000此https://github.com/kubernetes/kubernetes
kubernets是go语言研发，运行需要配置环境变量
https://kubernetes.io 官方站点
亚马逊的AWS 阿里云运行也是没什么问题的
laas，底层有paas
k8s会引入一堆的新概念，这种编排工具主要实现跨主机管理的，容器主机需要有多个，所以k8s本来就代表集群
k8s的集群架构是master，agent模型（node）
第一个节点是master，是调度的统一分配框架，提供API的监听，所有客户端的请求都是发给这个API（创建容器，删除容器，）都向master上的API接口发送请求
master收到请求以后还有另外的组件，Scheduler调度器，由调度器负责将用户，比如创建，找node主机，看看哪个比较空闲，将其作为调度的目标主机
由此主机在本机启动用于所需要启动的容器，包含创建
集群节点必须要连接到合适的registry，下载好合适的镜像到本地
对整个集群来讲，master到底运行了多少容器，每个容器有多少属性，运行在哪个主机上，这些信息，要找一个位置存储，放在一个强一致性，拥有容错能力的键值存储集群服务存储
这个键值存储能够多节点构建成集群，而且数据支持强一致特性，一个节点挂了并不会访问其他数据访问，master节点挂了，重启起来依然没什么问题，能够继续访问
如果某个node挂了，在master上还有一个组件，叫control manager控制管理器，监控你所部署的，每一个容器的数量是否够，每一个容器要求1个，如果检查发现挂掉了，再重新调度一个节点启动一个
比如tomcat服务启动三个容器，需要确保你有三个，多了杀掉，少了补全受到请求，给完成调度
etcd就是强一致的kv存储（raft协议，简单快速一致的，容易理解的，键值存储只是一个核心简单的功能）go语言，轻量高性能，非常相似zookeeper（用的协议是一种变化的paxos协议） java
整个kubernetes整体框架就是有一个master主机，master主机完成的任务，apiserver ，接收请求，完成请求，调度用户任务scheduler
任何状态是否满足 controller-manager，监控目标状态接口
node主机跑
1.kubelet 作为agent端进程，每个节点都需要运行，所有master发来的任务都是由kubelet执行的，包括启动容器
docker/rkt容器部署环境
kube-proxy代理对本节点上的服务的访问
cli命令行工具（著名工具kubectl），ui图形工具（dashboard），api程序接口
Kubernetes
架构：master/agent
master主机：
kube-apiserver
kube-scheduler
kube-controller-manager
agent主机（node）：
kubelet
container runtime(docker/rkt/…)
kube-proxy 接收用户请求发送到container上的代理，类似nginx，haproxy反代
这些就是kubernetes核心架构组件
各 node链接到Registry，下载镜像，运行容器
kubernetes master要能够输出API接口，让用户通过三种方式。API,UI,CLI的方式来链接调用服务
组成kubernetes
master的数据存储在etcd上
kubernetes三个核心组件+etcd（运行在其他主机上，本身也是个集群）
kubernetes的node节点
**对每个node节点，都需要要引入docker的运行环境
kubelet代理，agent
kube-proxy 服务访问的代理
1.pod是kubernetes的核心组件而不是容器
2.addons附件（插件可以理解为整个系统的功能之一，附件是有这个功，整个生态有整个功能，要用需要额外安装，并不是系统不可分割的一部分）dns是著名的附件，ui图形化接口，需要用就需要安装
3.fluentd日志收集工具，（logstash）
**
对整个kubernetes，pod是最为核心的组件，pod内部是用来跑容器的，pod是容器组，container group容器组，
在同一个pod的容器，共享同一个网络名称空间，所以是joined conatiner 联盟，（大家拥有同一个ip地址或者同一组网络接口，lo即可通信，）
pod特别像虚拟机。，
在docker中，每个容器是用来运行一个程序的，把多个容器和起来使用同一个ip地址，pod就非常像虚拟机，回到虚拟机的方式就是使用joined container ct
所以每一个pod都是联系比较紧密的容器，需要通过lo接口通信的，都放在同一个pod中，就表明地址属于pod而不属于容器的，pod自身如何拥有ip地址，它自己也需要作为一个容器才可以
pod是一个虚拟的概念，但是也需要一个容器来表示pod的基础架构，意味只要启动pod，在pod内部必须有一个容器，只不过这个容器一直处于pause状态，没有其他作用就是附加一个ip地址，任何后来启动这个pod中的容器就直接join到这个基础架构容器上来
可以把一组联系非常紧密的容器放在一起，一个nginx容器跑一个nginx，但是将来收集日志该怎么收集，（elk得需要跑一个beat来收集日志或者logstash）把日志放在卷上，多个容器跑在同一个pod中，共享一个ip地址，也是有同一个卷，nginx负责写，filebeat负责读，读出来，再送给elk或者redis
所以有时候需要多个应用程序跑在一起才能完成某个任务的，现在就需要把一个程序跑在紧密的组容器中，
所以kubernetest就造出的容器组件，pod，只有这么紧密的才需要跑到一个pod中
NT架构，nginx，tomcat不止一个，不能把tomcat放在一个pod中，如果放在pod中，就不能使用相同的端口了，就相当于再一个虚拟机上跑了多个tomcat实例，所以还需要把三个tomcat跑在三个pod中，每个tomcat应该还有filebeat 去收集日志
现在有三个pod都是tomcat的，加入前端有nginx，用户请求要调度到三个tomcat容器中，这三个tomcat容器分别跑在三个pod上，用户的请求需要从nginx的pod发送到三个tomcat的pod
如何去引用三个pod，容器都有生命周期，重启了ip地址会发生改变，所以不能用ip地址反代，每一个pod用dns解析其名字和IP地址对应关系，引用的时候引用名字，而不引用主机，
这种方式有一个问题，dns称为必须要配置的服务，还要确保每个pod都要实时访问，更重要的是，如果跨界点的话，这三个pod在不同的节点上，这样访问起来会更加麻烦，很难用一个名称引用，这时候可以这么解决问题：
ip地址是发生变化的，每创建一个pod就打一个标签，标签一般是kv组成，（k=app：v=tomcat），因此每一个tomcat的pod都打标签，第二个，第三个pod都有同一个标签，所以不管ip地址是什么，标签是它就可以引用，只要标签相同的就可以归集到组，每一个组取一个ip地址当作对外通信的地址，因为他们有可能运行在不同的主机之上，为了引用这些pod，不用ip地址来引用，而靠每创建一个pod来打一个标签label，把对应的几个标签收纳起来，把标签归集成组，给这个组取一个ip地址，
把标签里值相同的都归成group，给这个组取一个名或赋予一个ip地址，所以以后有人想要访问tomcat，只要访问这个地址即可，这个ip地址是固定的，
从这个角度来讲，一组pod所形成的组，赋予一个ip加上这一组所有的信息，归集起来，就叫做一个service，可以认为是个tomcat服务，请求这个服务不用向任何pod发送请求，这需要向这个service对外宣称的ip发请求，它自己的ip轮询到不同的pod上，所以称为服务service
对kubernetes来讲是重要组件
service如何定义，由一组容器+ip组成，必须把一组功能相同的pod归集成组，（如何知道功能相同）启动一个pod，给个键，这些键对应的pod值相同，挑选键以后确保值相同，的操作叫做select，服务的挑选器，
所以一组服务想通过的pod可以组成一个服务，统一颜色可以理解为label一样，由service自动归集成组，对外统一一个ip地址，所以service更像一个调度器，就是一个iptables规则
service是一个逻辑概念，任何概念都需要实现，把一组pod结合起来赋予一个ip地址以后，作为同一个ip地址来访问的，kube-proxy
service定义好了，展现出来的就是kube-proxy中的一个代理，这个代理就是一个负载均衡器
controler manager有三种实现方式，
rc replication controller
rs replication sets
每一个容器占了多少cpu，内存，io
cAdvisor各种资源使用和性能统计数据，每个容器只能运行一个程序，要收集这个容器的性能数据，不可能在容器里在运行程序了，只好再运行一个容器，这个容器就是帮你收集各个pod运行容器的性能数据和使用率数据，探测只需要向主机探测即可，主机内核肯定分了很多用户空间，向用户空间收集数据，就可以知道容器的使用情况
cAdvisor就是主机上的，各容器性能数据和使用率数据的统计代理程序，kubernetes自带组件
kubernetes调度也是以pod调度，而不是容器
同一个pod中的容器之间的通信靠IPC，进程间通信，共享内存，LO接口
pod的里的容器拥有同一个主机名
同一个pod里的各容器共享ip地址，网络名称空间
同一个pod内的各容器使用同一个卷
如何去部署一个pod
需要一个配置文件，来部署好要启动的内容
pod定义的文件 definition
replication controller 复制控制器，控制管理决定运行在哪个节点上
这些是rc replication controller实现方式
在一个node上有很多pod，颜色相同代表label的键值一样，可以把红色label的做成一个service，用户向service发请求，service合理调度到不同的pod上
紫色的lable在定义一个service，向它发请求，也合理调度到pod上
service可以想像成访问容器的统一接口，而且本身隐含调度功能，
label定义好以后，可以指明labels是哪一个，来定义出一个选择器，以便将多个pod归集成组。label就是附加在pod之上的 kv键值对
对kubernetes来讲，每一个对象都可以附加label，不光是pod
service就是一个静态API对象，固定ip地址，不再需要服务发现了，因为地址是固定的
一个service就是一个virtual ip，client向virtual ip发请求，分发到各pod上，
这个VIP是由kube-proxy来管理的，service只是一个逻辑概念，真正能去配置生成ip地址，而且用户请求合理调度到pod上的，是kube-proxy，
如果proxy一变，vip地址就改变了，kube-proxy要负责监视所有的服务，以确保服务对应的pod，变化时要立即更新，对应的规则，kube-proxy其实就是靠iptables规则来实现的
proxy模式由两种
1.在userspace中
还有一种是在主机上实现iptables规则
在k8s的中，服务发现
一种使用环境变量，一种使用dns
dns是一个非常核心的附件，1.3实现的时候交skydns，1，3以后附件叫kubedns，这个附件基本上要安装kubernetes以后要安装生成的，gcr。io
需要自己编辑分配才能安装
每一个主机上都有可能被master上 的Scheduler调度器，调度运行很多pod，pod一旦被调度完以后，pod是不是够数，需要找controller-manager来确保
Scheduler调度哪个节点，controller-manager确保是否够数，不够数再想master请求不够的数量，Scheduler再次调度到合理的节点上
而到底创建哪些各pod是靠用户通过api来发请求来决定，不是集群自己决定的，运行以后，都表现为一个个pod
（比如由 三个pod，在第一个节点有两个，在第二个节点有一个，假如下面的挂掉了，如果数量不够了controller-manager就向apiserver发请求，apiserver给Scheduler发请求，在启动一个pod，所以就有可能后来变成第一个节点一个，第二个节点两个，地址会经常发生变化
pod很多，nginxpod要运行，tomcatpod要运行，由调度器根据算法来决定，哪个调度到哪些节点，哪个运行哪些pod
划分成组，把pod固定在一起，给pod设定label，通过标签相同的方式，定义成组，标签相同的组，定义出的组件叫服务，service，服务有一个固定的ip地址，在每一个主机上都应该有一个服务进程，叫kube-proxy，
等于配置一个静态ip地址，节点有多各，每个节点都有可能作为访问入口的，给网卡配置一个静态的ip地址，可以这么想象，但是不需要这么配置，目标只要是这个ip地址的，在当前节点上有几个与之匹配的pod，就调度过来，如果不在这个节点上就转发给合理的节点，
kube-proxy定义的规则将一组服务器，定义成service
就算不是外部用户调用，给nginx反代逻辑也一样，所有用户请求直接发给nginx，nginx地址会变，定义一个服务，叫nginx，定义到nginx的服务，设定为静态地址，这个服务由kube-proxy负载监听这个静态地址的访问，对用户请求到达kube-proxy的时候kube-proxy转发给nginx，而nginx是一个反代服务，反代给tomcatpod，tomcatpod地址会变，不转发给tomcatpod，而是转发给tomcat servcie，service会自行进行调度
监控，和调度都让kubernetes做了
pod和service是核心组件
docker的网络，每一个节点都由一个docker0桥，默认拥有的地址是172.17.0.0的地址，跨界点的容器通信，出栈需要snat，入站需要dnat，非常麻烦
但是kubernetes不这么做，k8s不通过nat就能互相通信，而且地址各不相同，
下面的路由链接了很多网段，其中给第一个主机上的docker0桥，
10.99.0.0/16下面的子网 10.99.0.0/24 10.99.1.0/24，就有256个子网0-255
整个集群用的是10.99.0.0/16的地址，每一个节点上的docker0桥用的是子网地址，所以第一个桥用的是 10.99.0.0/24，里国外主机上是用10.99.1.0/24，子网各不相同
主机间的容器通信，需要把报文发送给桥，随后可以在宿主机上，发起隧道功能，gre，ovs，把用户请求拿过来扔到另外的物理机上去，并链接到另外的桥，发现是本地的，就发给容器了
这种隧道称为叠加网络 overlay network
但kubernetes自己没实现整个网路模型，需要我们自己实现
最简单的实现工具有，flannel，calico contiv等 ，一般使用flannel来解决叠加网络
需要部署etcdcluster
一般生产部署k8s有两种方案
一个节点当etcd，k8s集群，一个当master，多个node，开发测试环境
生产环境，etcd需要集群，奇数节点，节点越多，性能越好，容纳数据越多，最基础三节点，
部署k8s集群，master节点需要2个，（master本身无状态，因为用的rusltfull风格的api
，所以可以用nginx反代），nginx做个高可用，这就是部分容器化
各个节点需要多个，不需要做高可用，节点挂了，在其他启动一个pod即可
