kubernetes概念笔记

[geniusrabbit]

Study of kubernetes

kubernetes结构图-来源

基本概念和术语

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自动转移到其它节点上.
<br>
node上的关键进程

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

Pod

每个pod有一个根容器Pause,还有一个或者多个用户业务容器
<br>
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类似，但具有严格的命名规则