pod: lable lable-selector
lable key=values
pod: pod可以叫做是有生命周期的东西。调理器将其调理到某节点运行后，他的任务终目也就被删除或停失了。
自主式pod，（自我打点的POD）
控制器打点的pod。（建议使用这种POD）
ReplicationContrller 副本控制器。如果我们启动一个nginx_pod，

同一pod内多个容器通信，lo
各pod间有通信，

NMT：N:NGINX,M:MYSQL,T:TOMCAT

简单地说，kubernetes还是一个打点跨主机容器化应用的系统，实现了包孕应用部署，高可用打点和弹性伸缩在内的一系列基了础成果并封装成为一套完整，简单易用的RESTful API对外供给处事，
kubernetes引入了专门的POD，从而成立了围绕着POD这个可以视作单个容器的“容器组”展开的，当容器组取代成了为系统中的主要粒度。
kubernetes供给了APIServer,scheduler,kubelet等底层枋心组件，从而使用得用户能够安心打点成行上万个容器实例，更供给了pod，replicagion controller，service等设计理念。
kubernetes供给了，容器组，跨主机网络，负载均衡，等一系列关键的上层容器处事。

在k8s之上我们运行了容器，同一类容器（同一类pod），
１、如果用户请求达到时我们该如何接入请求。到底给哪一类pod中的哪一个pod卖力措置惩罚惩罚了。
２、POD自己是要有所为的控制器来打点的，尽量不要人手工去打点，在k8s上pod有两类，（１）自主式pod，（自我打点），我们创建以后仍然需要提交给APIserver，由APIserver接收以后
借助于调理器将它调理至指定的node节点，由node启动此pod，而后，如果pod中的容器呈现故障，需要重启容器，那是由kubelet来完成的。但是如果节点故障了，这些pod也就消掉不见了，
（２）控制器打点的pod，正是控制器这种机制的使用，在kubernetes集群的设计中，pod就被称为有生命令周期的东西，有调理器将其调理至集群中的某节点运行以后，他的任务结束后就被删除或停失了。
但是有些任务，传统意义上的如ngxin、tomcat他们是做为守护进程运行的，这种要是运行成pod或容器的话，我们要确保他时刻得于运行状态。一旦呈现故障必需要在第一时间发明，要么是代替他要么是重启他。
k8s为些供给的工具就叫pod控制器。

pod控制器有很多种，最早的一种就是replication controller，（副本控制器）

当我们要启动一个pod时，好比是启动一个nginx的pod，这个pod不够了，那我们再启一个pod，这个pod就叫做副本，其实每个pod都可以叫做是副本，那么控制器就专门控制着同一类pod资源的各类副本。
一旦副本数量少了，他会自动加一个补够，如果此中的一个pod被调理到第三个节点上运行，但是这个节点down机了，那么控制器会发明少了一个pod，控制器会从头请求apiserver借助于Scheduler调理以后找一个此外的节点
启动一个pod。还可以实现滚动更新，好比此前启动的容器是靠一个１.０版的镜像启动，后来我做了一个１.１版的镜像，需要把这些pod中对应的容器替换为１.１版本镜像，可以先关失一个１.０镜像的容器或者先创建一个１.１镜像
的容器。可以在更新的过程中姑且超过设定的副本数量，去失一个１.０镜像的副本行了。以此类推，这就叫滚动更新，也撑持滚动更新的逆反操纵叫回滚。

到了新版时有了新的控制器，ReplicSet叫副本集，不直接使用，他有一个声明是更新的控制器，是Deployment来卖力打点。我们用的最多的就是他，但是Deployment只能卖力打点那些无状态的打点应用，有状态的应用使用statefulset
如果我们想在每一个node上运行一个副本，而不是随意运行，还需要一个DaemonSET,如果运行功课Job，如果运行周期性功课就叫Ctonjob

Deployment还撑持二级控制器叫HPA，程度pod自动伸缩控制器。如：有两个nginx的pod不敷以承载用户访谒了，那就只有再加更多的pod了。
到底要加几个ngixn的pod，HPA会自动监控着的。HPA（HorizontalPodAutoscaler）是依据当前系统的可用资源不超某一个指定值的前提下自动增加pod数量。

好比有两个pod，pod有生命周期，也就是万一pod地址的节点down机了，pod有可能要在其他节点上重建，而重建完的pod和本来的pod不是同一个pod，里边运行的是同一个处事，但pod已经不是以前阿谁pod了，而且每一个容器都有一个ip地点吧，新建的
pod的ip地点和些前阿谁pod的ip地点也是不一样的，这么一来就有问题，我们客户端怎么去访谒这些pod了，给与处事发明，客户端每一次去访谒后端对应的处事时，他需要先去访谒一个位置有没有这个处事。这个位置就叫中间层也叫Service，
Service只要不删除他的地点是固定的名称也是固定的，当客户端需要写在配置文件中访谒某一个处事时，他不用发明也不用自动去发明某一个成果，他只需要要在配置文件中写明这个处事的地点或者名称就行，而这个处事是一个调理器还可以起到调理的成果。
不单能供给一个不变的访谒入口，还可以把请求送到后真个pod容器里。一旦pod死失了，再新建一个pod，新建的pod当即会被service关联进来，把他作为service后真个可用pod资源, 客户端访谒处事都是通过ip加端口或者是主机名加端口的。service关联后真个pod不是通过ip加端口或者是主机名加端口的方法，
而是通过在创建pod时的元数据lable来关联的，service把这个pod关联进来后，再动态探测这个pod的ip地点和端口，并做为本身动态调理后端可用的盈千用处事器主机东西。
在k8s上service并不是什么应用措施，也不是实体组件，他只不过是一个iptables的dnat法则，service作为一个kubernetes的东西来讲，有service的名称，service的名称也相当于是这个处事的名称。
而且名称可以被解析，可以把service的名称解析为service的ip地点，名称解析靠的是DNS，装完k8s集群时你会发明第一件事就需要在你的k8s集群上部署一个DNS的pod，以确保各service能被正确解析。这种处事是k8s自身处事就要用的pod，我们把它叫做根本级的系统架构所使用的pod，他们也被称为集群的附件（AADOns附加组件）
DNS只k8s众多附加组件中的一种，它可以动态转变，动态创建、动态删除、动态改观。好比你把service名称改一下，它会自动触发dns记录中的解析名称也会转变的，

客户端去访谒某一处事时，可以直接访谒处事的名称，然后由集群中专用的DNS来卖力解析成service的地点，因此这个访谒依然是由service做为代办代理访谒实现的，而代办代理是由端口代办代理，就是由dnat实现的，dnat是多方针调理，对付linux来讲，iptables已经把负载均衡的主要成果交给ipvs来实现，因些如果service背后的同一类pod有好多是由dnat来实现的时，
在调理效果上可能不太尽人意，因此在１.１１版的傍边已经把其iptables的法则进一步改成了ipvs了，，也就是意味着当你创建service时就相当于生成了一条ipvs，中不过是nat模型的ipvs，因此撑持用户指定各类调理算法，

外接调理器已经脱离k8s的控制了，他不能基于k8s以命令的方法创建了。如果你是一个IAAS云计算环境，有一种处事叫LBaas负载均衡级处事，如果我们把k8s集群运行在阿里云或者是亚马逊云上，阿里云或者是AWS是撑持LBaas的，我们k8s可以对外挪用低层云计算环境API接口创建一个service这个service要对外开放，用他来创建一个外接调理器。
service只是调理流量的，控制器用来打点pod的。