k8s小记-（2）核心概念介绍

Pod-容器组

Pod是Kubernetes中最常见的资源之一。它们是一个或多个容器的集合。Pod中的容器共享网络和存储，同一Pod中的任何容器都可以通过localhost进行相互通信。

Pod被设计为非持久化的，可以随时将Pod重新部署到不同的节点上运行。只要的Pod重启，容器也也相应会重启。如果Pod重启，就会分配另一个IP地址。因此，不能依赖于IP地址。通过IP直接与Pod进行通讯可能会有问题。可以与Pod进行通信的抽象称为K8S服务。K8S服务为我们提供稳定的IP地址和DNS名称。

Pod是K8s集群中所有业务类型的基础，可以看作运行在K8s集群中的小机器人，不同类型的业务就需要不同类型的小机器人去处理。目前K8s中的业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet和PetSet。

Deployment-部署
部署表示用户对K8s集群的一次更新操作。部署是一个比RS应用模式更广的API对象，可以创建，更新一个新的服务，或者滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新的RS中的副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作 。

一个Deployment = 一组Pod + 一个Replica set（副本集）。Replica Set负责环境中有指定数量Pod副本在运行，如果少于指定数量的Pod副本， Replication set会启动新的Container，反之杀死多余的以保证数量不变。

Job-任务
Job是K8s用来控制批处理型任务的API对象。批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出了。成功完成的标志根据不同的spec.completions策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功型任务保证有N个任务全部成功；工作队列型任务根据应用确认的全局成功而标志成功。

DaemonSet-后台支撑服务集
长期伺服型和批处理型服务的核心在业务应用，可能有些节点运行多个同类业务的Pod，有些节点上又没有这类Pod运行；而后台支持服务的核心关注点是K8s集群中的节点（物理机或虚拟机），要保证每个节点上都有一个此类Pod服务运行。节点可能是所有集群节点也可能是通过nodeSelector选定的一些特定节点。典型的后台支持型服务包括，存储，日志和监控每个节点上支持K8s集群运行的服务 。

PetSet-有状态服务集
K8s在1.3版本里发布了Alpha版的PetSet功能。。RC和RS主要是控制提供无状态服务的，其所控制的Pod的名字是随机设置的，一个Pod出故障了就被丢弃掉，在另一个地方重启一个新的Pod，名字变了、名字和启动在哪儿都不重要，重要的只是Pod总数；而PetSet是用来控制有状态服务，PetSet中的每个Pod的名字都是事先确定的，不能更改。PetSet中Pod的名字作用用于关联与该Pod对应的状态 。

对于RC和RS中的Pod，一般不挂载或者挂载共享存储，保存是所有Pod共享的状态，各个Pod之间没有区别；对于PetSet中的Pod，每个Pod挂载独立的存储，如果一个Pod出现故障，从其他节点启动一个同样名字的Pod，要挂载上原来Pod的存储继续以它的状态提供服务。

Replica Set-副本集
RS是新一代的RC， 提供同样的高可用能力，区别，RS 能支持更多种类的匹配模式。副本集一般不单独使用，而是作为Deployment的状态参数使用。

Service-服务

在Kubernetes的世界里，虽然每个Pod都会被分配一个单独的IP地址，但这个IP地址会随着Pod的销毁而消失，这就引出一个问题：如果有一组Pod组成一个集群来提供服务，那么如何来访问它呢？Service！

一个Service可以看作一组提供相同服务的Pod的对外访问接口，Service作用于哪些Pod是通过Label Selector来定义的。

• 拥有一个指定的名字（比如my-mysql-server）；
• 拥有一个虚拟IP（Cluster IP、Service IP或VIP）和端口号，销毁之前不会改变，只能内网访问；
• 能够提供某种远程服务能力；
• 被映射到了提供这种服务能力的一组容器应用上；

如果Service要提供外网服务，需指定公共IP和NodePort，或外部负载均衡器。

服务发现

服务发现完成的工作，是针对客户端访问的服务，找到对应的后端服务实例。例如，在K8s集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。

负载均衡

在K8s集群中微服务的负载均衡是由Kube-proxy实现的。kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8s的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。

Kubernetes还包括以下几个核心组件：

etcd保存了整个集群状态
apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和服务发现等机制
controller manager负责维护集群的状态，比如故障检测、自动扩容、滚动更新等
scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上
Kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理
Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）
Kube-proxy负责为service提供cluster内部的服务发现和负载均衡
除了核心组件，还有一些推荐的Add-ons：

kube-dns负责为整个集群提供DNS服务
Ingress Controller为服务提供外网入口
Heapster提供资源监控
Dashboard提供GUI
Federation提供跨可用区的集群
Fluentd-elasticsearch提供集群日志采集、存储与查询