0%

《Kubernetes》Kubernetes介绍

简介

Kubernetes最初源于谷歌内部的Borg,提供了面向应用的容器集群部署和管理系统。

Kubernetes的目标旨在消除编排物理/虚拟计算,网络和存储基础设施的负担,并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。

Kubernetes 也提供稳定、兼容的基础(平台),用于构建定制化的workflows 和更高级的自动化任务。

Kubernetes 具备完善的集群管理能力,包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。

Kubernetes 还提供完善的管理工具,涵盖开发、部署测试、运维监控等各个环节。

架构

Kubernetes主要由以下几个核心组件组成:

  • etcd保存了整个集群的状态;
  • apiserver提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制;
  • controller manager负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;
  • scheduler负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上;
  • kubelet负责维护容器的生命周期,同时也负责Volume(CSI)和网络(CNI)的管理;
  • Container runtime负责镜像管理以及Pod和容器的真正运行(CRI);
  • kube-proxy负责为Service提供cluster内部的服务发现和负载均衡;

除了核心组件,还有一些推荐的插件,其中有的已经成为CNCF中的托管项目:

  • CoreDNS负责为整个集群提供DNS服务
  • Ingress Controller为服务提供外网入口
  • Prometheus提供资源监控
  • Dashboard提供GUI
  • Federation提供跨可用区的集群

k8s_architecture

云厂商集成K8s的设计图

k8s_architecture1

Kubernetes系统架构遵循客户端/服务端(C/S)架构,系统架构分为Master和Node两部分,Master作为服务端,Node作为客户端

Kubernetes系统可以具有多个Master服务端,可以实现高可用。在默认的情况下,一个Master服务端即可完成所有工作。

主控节点

Master服务端也被称为主控节点,它在集群中主要负责如下任务

  1. 集群的“大脑”,负责管理所有节点(Node)
  2. 负责调度Pod在哪些节点上运行
  3. 负责控制集群运行过程中的所有状态。

主控节点主要包含如下组件

  1. kube-apiserver组件:集群的HTTP REST API接口,是集群控制的入口
  2. kube-controller-manager组件:集群中所有资源对象的自动化控制中心。通过etcd选举实现高可用(领导者节点运行组件,候选节点阻塞)
  3. kube-scheduler组件:集群中Pod资源对象的调度服务,负责在Kubernetes集群中为一个Pod资源对象找到合适的节点并在该节点上运行,可以当成Pod Controller。通过etcd选举实现高可用

工作节点

Node客户端也被称为工作节点,它在集群中主要负责如下任务

  1. 负责管理所有容器(Container)
  2. 负责监控/上报所有Pod的运行状态。

Node节点上的工作由Master服务端进行分配,比如当某个Node节点宕机时,Master节点会将其上面的工作转移到其他Node节点上。

Node节点主要包含如下组件

  1. kubelet组件:负责管理节点上容器的创建、删除、启停等任务,与Master节点进行通信。一旦 Scheduler 将 Pod 调度到某个节点上,该节点的 Kubelet 就会接管该 Pod 并开始部署,可以把 Kubelet 当成Pod Controller。
  2. kube-proxy组件:负责Kubernetes服务的通信及负载均衡服务。有 iptables 代理模式(利用iptables) 和 IPVS 代理模式(利用IPVS 内核模块) 两种模式
  3. container组件:负责容器的基础管理服务,接收kubelet组件的指令。

简单的类比

一个人两只手在搬砖(类比是为了帮助理解记忆,不恰当之处请勿喷。。)

k8s 一个傀儡人
kube-controller-manager 傀儡的控制者(自动的)
kubectl 傀儡的控制者(手动的)
kube-apiserver 大脑中下达命令以及获取人体信息的部分
etcd 大脑中存储记忆的部分
kube-scheduler 控制砖放在哪只手上
pod
node
kubelet 手的管控者
CRI-O运行时 支撑手活动的血肉
kube-proxy 神经系统
container 手指

Kubernetes 重要的子系统

  • 架构 Architecture
  • 应用 Apps
  • 存储 Storage
  • 网络 Network
  • 权限 Auth
  • 节点 Node
  • 调度 Scheduling
  • 命令行 CLI
  • 多集群 MultiCluster
  • 云平台 CloudProvider
  • 扩展性 Scalability
  • 弹性伸缩 Autoscaling
  • 监控日志 Instrumentation

https://github.com/kubernetes/community 可以跟踪各个子系统的开发进度

以 “wg-“ 开头的目录,例如 “wg-resource-management”

“wg” 是 working group 的简称,是针对需要涉及多个 SIG 之间合作而展开的一种工作组,独立于任何 SIG

例如 resource management 会涉及到 Node、Storage、Scheduling 等 SIGs

一个命令的执行过程

CRI-O运行时

一开始K8s的worker节点中的kubelet是直接使用了docker引擎,直接跟docker引擎打交道,docker控制着容器的生杀大权

这样的话,k8s与docker紧紧耦合,k8s无法使用任何其他的容器引擎,而且docker引擎除了容器管理的功能外,还有一些k8s用不到的很多功能
,这对k8s来讲有些臃肿

k8s其实只需要一个容器运行时(容器管理、镜像管理),而docker不仅包含了containerd容器运行时,还有一些其他的无用功能

所以后来k8s提出了容器运行时接口(CRI)规范,希望通过这个规范可以移除掉docker的依赖,实现解藕

CRI有多种实现,例如Dockershim,CRI-O,containerD

另外,容器运行时需要运行到各大操作系统当中,容器管理功能在每个系统中都有些差异,所以容器运行时需要增加一个针对容器管理的抽象层来屏蔽各大操作系统的差异,同样是通过接口规范

所以出现了OCI(Open Container Initiative,开放容器计划),OCI提出了明确的容器管理规范,该规范有助于实现多平台支持(Linux,Windows,VM等)

Runc是OCI的默认实现

综上所述,CRI-O是一个容器运行时,通过OCI规范使用了Runc作为容器管理的工具,使用了开源Containers项目的containers/image和containers/storage来做镜像管理

kubelet通过CRI规范与CRI-O打交道

通过CRI规范,k8s可以实现自由更换容器运行时,而通过OCI,容器运行时可以自由更换容器管理组件




微信关注我,及时接收最新技术文章