kubernetes

My Study of kubernetes

kubernetes结构图-来源

image

基本概念和术语

master

功能:集群控制节点,负责整个集群的管理和控制,属于首脑

master节点上运行的关键进程

Kubernetes API Server(kube-apiserver):提供HTTP Rest接口的关键服务进程,kubernetes里所有资源的增删查改操作的唯一入口,也是集群控制的入口进程
Kubernetes Controller Manager(kube-controller-manager):kubernetes里资源对象的自动化控制中心
Kubernetes Scheduler(kube-scheduler):负责资源调度(Pod调度)的进程

Node

除了Master,kubernetes中的其它机器被称为node节点,node节点是kubernetes集群中的负载节点,每个node都会被分配工作负载(docker容器),当某个node出错时,该节点的任务会被master自动转移到其它节点上.

node上的关键进程

kubelet:负责pod对应的容器的创建,启动停止等任务,同时与master密切协作,实现集群管理
kube-proxy:实现kubernetes Service的通信与负载均衡
Docker engine(docker):Docker引擎,负责本机的容器创建和管理

Pod

每个pod有一个根容器Pause,还有一个或者多个用户业务容器

Why kubernetes have Pod?

在一组容器作为一个单元时,很难对整体进行操作,引入业务无关并且不易死亡的Pause容器作为Pod的根容器,以它的状态代表整个容器组的状态
Pod里的多个业务共享Pause里的IP,共享Pause容器挂接的Volume,既简化了业务之间的通信问题,也解决了文件共享问题

Label

功能:Label可以附加到各种资源对象上,例如node,pod,service,rc等,一个资源对象可以定义任意数量的Label,同一个Label也可以添加到任意数量的资源对象上去,以提供Label Selector来选择对象

标签选择方式:

等式:name=redis-slave,name!=redis-slave
集合:name in (redis-master,redis-slave),name not in (redis-master,redis-slave)

Label和Label Selector 共同构成了kubernetes系统中最核心的应用模型,使得被管理对象能够被精细的分组管理,实现整个集群的高可用性

Replication Controller(RC)

管理 Pods 的生命周期。它们确保指定数量的 Pods 会一直运行，还有实现资源伸缩。

定义RC实现Pod的创建与副本数量的自动控制
RC 通过Lable Selector机制实现对副本的自动控制
通过改变RC的Pod副本数量，实现Pod的扩容或缩容
通过改变RC里Pod模板中的镜像版本，实现Pod的滚动更新

Deployment

Deployment可以认为是RC的升级版，最大的区别是我们可以随时知道POD容器的部署进度

使用场景:
- 创建一个Deployment对象来生成RC并完成Pod副本的创建过程
- 检查Deployment的状态看部署动作是否完成
- 更新deployment以创建新的Pod(升级)
- 如果当前Deployment不稳定则回滚到早先版本
- 暂停Deployment以便于一次修改多个PodTemplateSpec的配置项，之后再进行发布
- 扩展Deployment以应对高负载
- 查看Deployment的状态，以此作为发布是否成功的指标
- 清理不在需要的旧版本RC

Horizontal Pod Autoscaler(HPA)

HPA也是一种资源对象，通过追踪分析RC控制的pod的负载变化情况来确定是否需要针对性地调整目标pod的副本数（增加或者减少）
Pod负载的度量指标:

CpuUtilizationPercentage（CPU利用率）,取所有副本自身CPU利用率的平均值（需要定义Pod Request值）
应用程序自定义的度量指标，比如TPS或者QPS

StatefulSet

用于实现有状态的集群管理，可以将它看做Deployment/RC的一个变种
特性:

StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群的其他成员
StatefulSet控制的Pod副本的启停顺序是受控的，如StatefulSet名叫zk,则第一个叫做zk-0，第二个叫做zk-2，依次类推
Stateful里的Pod采用稳定的持久化存储卷，通过PV/PVC实现

Service

service定义了一个服务的访问入库地址，前端应用（Pod）通过这个入口地址访问其背后的一组由Pod副本组成的集群实例，Service与其后端Pod副本集群之间则是通过Label Selector来实现无缝对接的。RC的作用实际上是保证service服务能力和服务质量始终处于预期的标准。
一组Pod组成的服，客户端如何访问？每个Node上的kube-proxy进程负责把对service的请求转发的后端某个Pod的实例上，并在内部实现了服务的负载均衡与会话保持机制。但需要注意的是：service不是共用一个IP，而是每个Service分配了一个全局唯一的虚拟IP地址（ClusterIP），服务调用就变成一个TCP网络通信。
kubernetes的服务发现机制，Service对象都有一个唯一的ClusterIP以及唯一的名字，在老版本中通过自动注入环境变量将service的name与ClusterIP绑定，新版本中采用插件的方式引入了DNS系统，把service的name作为DNS域名，然后程序就可以通过service的name来建立通信连接了
外部系统访问service的关键在于3种IP，即：
- 1.Node IP node节点的IP地址，集群之外的节点访问集群内的服务时，必须要通过NodeIP进行访问
- 2.Pod IP pod的IP地址，Docker Engine根据dicker0网桥的IP地址段进行分类的一个虚拟的二层网络的IP地址
- 3.Cluster IP service的IP地址，虚拟的IP，它的特点：仅作用域service对象，由k8s管理和分配IP地址;无法被ping;只能结合service port组成一个具体的通信端口，单独的Cluster IP不具备通信基础;集群之内 Node/pod/cluster之间的通信与通常的IP路由与很大的不同
service的cluster IP无法供外部直接使用，但通过指定服务的port绑定在节点的port上，即可进行访问；当pod位于多个node时，通过nodeip:port访问到的是nodeip所在node上的pod,如需负载可以考虑使用硬件负载均衡器或者Nginx

Volume

volume是pod中能够别多个容器访问的共享目录；k8s中volume定义在pod上，然后被pod中的多个容器挂载到具体的目录下；volume与pod的生命周期相同
类型:

emptyDir：Pod分配到node时创建的，它的初始内容为空，并且无需指定宿主机上对应的目录文件，pod从node上移除时，则emptyDir中的数据永久删除；emptyDir的用途有：
- 临时空间
- 长时间任务的checkpoint点
- 一个容器需要从另一个容器获取数据的目录
hostPath，在pod上挂载宿主机的文件或目录，
- 主要用途：
  - 容器应用生成的文件（如日志）需要永久保存时
  - 需要访问宿主机的文件时
- 注意事项:
  - 不同的node上具有相同配置的pod可能因为宿主机上的目录和文件不同而导致对Volume上目录和文件的访问结果不一致
  - hostPath无法纳入资源配额管理
NFS，使用NFS网络文件系统共享存储数据
其他类型：ceph、glusterfs等

Persistent Volume(PV)

PV是k8s集群中某个网络存储中对应的一块存储，它和Volume的区别：
- PV只能是网络存储，不属于任何Node，但可以在每个Node上访问
- PV独立于Pod定义
- PV目前支持的类型涵盖了很多公有云平台存储（gce、aws）以及一些网络文件系统（NFS）
Pod想申请PV时，需要先定义一个PVC（Persistent Volume Claim），然后在Pod的Volume中引用定义好的PVC

Namespace

Namespace通过将集群中的资源对象分配（逻辑上的）到不同的Namespace中，形成逻辑上的分组不同的项目、用户组等，便于实现多租户资源管理。默认的namespace是default
声明资源对象时，在metadata一项中可以指定，如namespace: dev

Annotation

注解与Label类似，但具有严格的命名规则

Kubernetes