Pod的生成过程

与API server的交互:API server收到kubectl命令或其他客户端的请求后，根据提供的系统参数生成一个pod对象。首先根据元数据匹配namespace，若能够匹配成功，就将提供的其他系统参数注入到pod对象中，同时检查这些系统参数是否正确，若都没有问题，最后成功生成一个pod对象，API server会将这个pod对象更新到etcd中，此时pod对象处于pending状态。

与scheduler的交互:scheduler通过watch机制监听etcd，当发现有新的pod对象生成时，就会选择部署pod对象的节点。首先，进行节点预选，检查集群中所有的节点，根据相应的指标进行打分，筛选出不符合要求的节点；之后再进行优选，根据节点的得分情况进行排序，选出最优部署pod对象的节点，如果有多个节点，就随机选一个部署。这些信息通过API server更新到etcd中。

与kubelet的交互:kubelet也是通过watch的机制监听etcd，当发现有新的pod要部署时，就会根据etcd中的pod清单信息在节点上部署。Pod对象中容器已创建，只要有一个容器启动或运行，pod就处于running状态；pod中的容器都正常运行(0)，是succeded状态；pod中至少有一个容器没有正常运行(non-0)，是failed状态；unkonwn状态表示与kubelet之间的联系出现问题。

pod的生成阶段:init container与main container。Main container包括:post start hook、liveness probe、readiness probe、pre stop hook.其中probe有三种类型:execAction、httpGet、tcpSocket。

控制器

Pod一般是由控制器创建、更新和维护的。控制器包括Replication Controller(rc)、Replica Set(rs)、Deployment(deploy)。RC是k8s中创建和管理pod的一种控制器，RS是在RC基础上发展的新一代控制器，两者没有本质的区别，不过RS支持集合化的(set-based)selector，能够更平滑的管理pod，RS一般和deployment结合使用；deployment能够更好的管理pod和RS。

Deployment支持两种strategy：recreate、rolling update，默认是rolling update(滚动更新)。Deployment是将pod资源置于两个不同的replica set下，旧控制器pod资源不断减少，新控制器pod资源不断增加，最后旧控制器上没有pod资源，新控制器的pod副本达到预期数量。

Kubectl set image 、kubectl rollout undo

Service

Service本质是定义一组pod集合及访问资源的策略。Pod集合一般由label selector决定的。Kube-proxy支持三种流量代理模式:userspace、iptables、IPVS。

Userspace：新的service创建时，所有节点上的kube-proxy会在节点上打开一个代理端口，并且向iptables中添加相应的规则，当有请求时就会重定向到代理的端口(由kube-proxy接受和调度)。然后再回到iptables，将请求分发到不同的pod。由于kube-proxy处于用户态，用户态和内核态的切换，会导致效率不高。

Iptables:新的service创建时，kube-proxy会在iptables中添加新的规则，请求在iptables会直接调度分发到相应的pod，由于一直处于内核空间，效率相较userspace大大提高。而且即使kube-proxy出现问题，也不会影响现有的service。

IPVS：当集群的规模较大时，iptables中的规则数量就是急剧增加，影响到性能，IPVS通过改变存储的数据结构很好地解决了这个性能问题。

Service类型:ClusterIP、NodePort、LoadBalancer、ExternalName

ClusterIP：默认方式，根据是否生成Cluster IP分为普通Service和Headless Service。

         普通Service:Service会在集群内部生成一个固定的虚拟IP(clusterip)，实现集群内部的正常访问。

         Headless Service：Service没有Cluster IP，也不用kube-proxy做代理和负载均衡，是根据DNS来进行解析

NodePort：Service将port映射到集群内每个节点相同的端口，实现集群外的访问服务。

Service中的三种Port：

port:表示Service暴露在Cluster IP上的端口，Cluster IP:port是集群内部访问服务的入口

nodePort:表示Service暴露在集群外的端口，Node IP:nodePort是集群外部访问服务的入口

targetPort:表示容器上的端口，请求的数据经过kube-proxy流入到后端容器的targetPort，最后进入容器。

Service中的三种IP:

Cluster IP:没有网络设备承载这个IP，是一个虚拟IP

Node IP:当service作为前端服务时，集群会在每个节点开启一个节点级的端口，对外提供服务。

Pod IP:Pod的IP。