Kubernetes入门学习

什么是Kubernetes？

Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署、调度和节点集群间扩展 。docker可以看出Kubernetes内部使用的低级别组件。Kubernetes同时还是支持Rocket（另一种容器技术）。

Kubernetes可以支持：

• 自动化容器的部署和复制
• 随时扩展或收缩容器规模
• 将容器组织成组，并且提供容器间的负载均衡
• 很方便地升级应用程序容器的新版本
• 提供容器弹性，如果容器失败就替换它

实际上，使用Kubernetes只需一个部署文件，使用一条命令就可以部署多层容器（前端，后台等）的完整集群：

$ kubectl create -f single-config-file.yaml

kubectl是和Kubernetes API交互的命令行程序。

注意： yaml是专门用来写配置文件的语言，非常简洁和强大，远比json格式方便。

概念解释

体现服务的架构图

体现角色的架构图

核心概念介绍

Pod-容器组

Pod是Kubernetes的基本操作单元，指定多个有关联容器（有调用关系依赖）构成一个Pod。Pod包含的容器运行在同一个Minion上（Worker Node），Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统。

Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

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

Deployment-部署

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的存储继续以它的状态提供服务。

适用于PetSet的业务

• 数据库服务MySQL和PostgreSQL
• 集群化管理服务Zookeeper、etcd
• 比普通容器更稳定可靠的模拟虚拟机的机制
  
  • 传统的虚拟机是有状态的，运维人员需要不断地维护它。容器刚开始流行时，用容器来模拟虚拟机使用，所有状态都保存在容器里，这是非常不安全、不可靠的 。使用PetSet，Pod仍然可以通过漂移到不同节点提供高可用，而存储也可以通过外挂的存储来提供高可靠性，PetSet做的只是将确定的Pod与确定的存储关联起来保证状态的连续性 。

Replication Controller-复制控制器

RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。动态的检查Pod的数量是否跟创建的时候指定数量一致，如果多于指定数量则会自动删除，如果多于指定数量则会自动创建。通过RC运行Pod比直接运行Pod更明智，RC会保证Pod的数量 。

Replica Set-副本集

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

Service-服务

RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务 。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以新的IP启动一个新的Pod，因此不能以确定IP和端口号 的方式提供服务。要稳定地提供服务需要服务发现和负载均衡能力。

• 服务发现

  服务发现完成的工作，是针对客户端访问的服务，找到对应的后端服务实例。例如，在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提供集群日志采集、存储与查询