Kubernetes架构

Kubernetes架构

Kubernetes对象

配置对象

服务(Service)

概念

Service是供客户端调用的一组业务功能接口(webapi)每个Service对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务，背后是运行在一组Pod上的程序。在Kubernetes集群中微服务的负载均衡是由Kube-proxy实现的。

节点(Node)

Pod运行所在的工作主机，可以是物理机也可以是虚拟机。Node是用来在至上运行kubelet管理的容器。

命名空间(Namespace)

命名空间为Kubernetes集群提供虚拟的隔离作用

密钥对象(Secret)

Secret是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。用以避免把敏感信息明文写在配置文件里。

RBAC访问授权

基于角色的访问控制（Role-based Access Control，RBAC）。RBAC主要是引入了角色（Role）和角色绑定（RoleBinding）的抽象概念。

用户帐户(User Account)&服务帐户(Service Account)

ConfigMap

Ingress

Label

ThirdPartyResource

存储对象

持久存储卷(Persistent Volume，PV)&持久存储卷声明(Persistent Volume Claim，PVC)

存储卷(Volume)

Kubernetes的存储卷的生命周期和作用范围是一个Pod（Docker的存储卷作用范围为一个容器）。每个Pod中声明的存储卷由Pod中的所有容器共享。

支持存储类型

支持多种公有云平台的存储，包括AWS，Google和Azure云

支持多种分布式存储包括GlusterFS和Ceph

支持较容易使用的主机本地目录hostPath和NFS

支持使用Persistent Volume Claim即PVC这种逻辑存储

策略对象

SecurityContext

ResourceQuota

LimitRange

资源对象

Pod

部署(Deployment)

部署表示用户对Kubernetes集群的一次更新操作。比RC更大，如部署可以标示RC减到0再增加到制定Pad数的复合操作。

后台支撑服务集(DaemonSet)

典型的后台支撑型服务包括，存储，日志和监控等在每个节点上支持Kubernetes集群运行的服务。

有状态服务集(PetSet)

而PetSet是用来控制有状态服务(RC控制无状态Pod)，PetSet中的每个Pod的名字都是事先确定的，不能更改。PetSet中Pod的名字的作用是关联与该Pod对应的状态。一般会有本地存储用以保存状态特点：（stateful）、宠物（pet）、有名（having name）、不可丢弃（non-disposable）如：ZK，Mysql，etcd等需要用PetSet管理。

副本集(Replica Set，RS)

RS是新一代RC，提供同样的高可用能力，能支持更多种类的匹配模式。

副本控制器(Replication Controller，RC)

通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。少于指定数目的Pod副本，RC就会启动运行新的；多于指定数目，RC就会杀死多余的Pod副本。

集群联邦(Federation)

Kubernetes的设计定位是单一集群在同一个Zone(跨主机同可用区)。而联合集群服务就是为提供跨Region(跨同地区可用区)跨服务商Kubernetes集群服务而设计的。

任务(Job)

Job是Kubernetes用来控制批处理型任务的API对象。和Service区别是运行有头有尾，任务成功完成就自动退出了。

CronJob

HorizontalPodAutoscaling

Etcd

作用：用以保存k8s集群所有的网络配置和对象的状态信息

网络插件flannel、对于其它网络插件也需要用到etcd存储网络的配置信息

kubernetes本身，包括各种对象的状态和元信息配置

raft一致性算法

raft

Etcd的原理解析

Etcd 架构与实现解析

Etcd官方文档

etcd v3命令和API

v3 api

注：Etcd V2和V3之间的数据结构完全不同，互不兼容，必要时需要设置ETCDCTL_API=3环境变量来指定V3版本的API。

分层架构

系统分层

生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴

Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等

Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

管理层：系统度量(如基础设施、容器和网络的度量)自动化(如自动扩展、动态Provision等)以及策略管理(RBAC、Quota、PSP、NetworkPolicy等)

应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）

核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境

分层架构图

设计原则

API设计原则

所有API应该是声明式的。

声明做了什么(what)，而不是声明怎么做(how)

API对象是彼此互补而且可组合的。

面向对象

高层API以操作意图为基础设计。

描述意图，从业务出发，而非如何实现，把实现留给低层API

低层API根据高层API的控制需要设计。

被高层API使用，考虑减少冗余、提高重用性的目的

尽量避免简单封装

不要有在外部API无法显式知道的内部隐藏的机制。(避免无谓的加壳)

API操作复杂度与对象数量成正比

避免步骤多了执行太慢

API对象状态不能依赖于网络连接状态。

保障断网了对象状态不是变成未知或新的状态

尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是非常困难的。

知道自己很容易，知道全局总是很难的

截图

控制机制设计原则

控制逻辑应该只依赖于当前状态

被依赖的节点恢复正常，依赖的就一定会恢复正常

假设任何错误的可能，并做容错处理

只能说听起来很美

尽量避免复杂状态机，控制逻辑不要依赖无法监控的内部状态

假设任何操作都可能被任何操作对象拒绝，甚至被错误解析

声明式设计，不要安排实现方应该怎么做(如应该“关闭节点”，而非“拒绝新连接，关闭端口，kill进程”)

每个模块都可以在出错后自动恢复。

对应第一条，能快速恢复，大错误就变成小错误

每个模块都可以在必要时优雅地降级服务。

优雅，故障隔离要做设计时就考虑好，基本功能高保障，高级功能必要时允许牺牲

操作API设计

声明式（Declarative）

要做什么： Do what ？

命令式（Imperative）

应该怎么一步步去做：How to do？

k8s的声明式API设计

K8S所有的操作都是声明式（Declarative），声明式操作在分布式系统中的好处是稳定，不怕丢操作或运行多次（幂等）。例如设置副本数为3的操作运行多次也还是一个结果，而给副本数加1的操作就不是声明式的，运行多次结果就错了。

核心组件

etcd

用以保存了整个集群的状态

apiserver

提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制

controller manager

负责维护集群的状态，比如故障检测、自动扩展、滚动更新等

scheduler

负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上（Model）

kubelet

负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理

Container runtime

负责镜像管理以及Pod和容器的真正运行（CRI）

kube-proxy

负责为Service提供cluster内部的服务发现和负载均衡

Add-ons

kube-dns

负责为整个集群提供DNS服务

Ingress Controller

为服务提供外网入口

Hipster

提供资源监控

Dashboard

提供监控GUI

Federation

提供跨可用区的集群

架构图

整体架构图

概念图

开放接口

CRI（Container Runtime Interface）容器运行时接口，提供计算资源

cri

CRI架构图

详细参考

CRI: the Container Runtime Interface

CRI接口(api.proto)

//容器和Sandbox运行时管理RuntimeService

// Version接口返回运行时名称，版本和API版本。 rpc Version(VersionRequest) returns (VersionResponse) {}

// RunPodSandbox接口创建并启动一个pod-level Sandbox. Runtimes 必须确保Sandbox成功处在Ready状态 rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse) {}

// StopPodSandbox接口停止作为沙箱内部的任何正在运行的进程，并回收分配给沙箱的网络资源（例如，IP地址）。//sandbox内的任何运行中的容器都必须被强制终止。这个请求是幂等，即使所有的相关资源已经被回收也不能返回错误，//kubelet 将在RemovePodSandbox接口被调用前至少请求本接口一次。//如果Sandbox变得非必须则相关资源将会第一时间被回收，因此，本接口预计会被请求多次。 rpc StopPodSandbox(StopPodSandboxRequest) returns (StopPodSandboxResponse) {}

// RemovePodSandbox接口将删除任何正运行在sandbox中的容器，容器将被强制终止并删除// 本接口是幂等哪怕sandbox已经被删除也不能返回错误。rpc RemovePodSandbox(RemovePodSandboxRequest) returns (RemovePodSandboxResponse) {}

// PodSandboxStatus接口返回PodSandbox状态，指定的sandbox不存在则返回错误。rpc PodSandboxStatus(PodSandboxStatusRequest) returns (PodSandboxStatusResponse) {}

// ListPodSandbox returns a list of PodSandboxes.rpc ListPodSandbox(ListPodSandboxRequest) returns (ListPodSandboxResponse) {}

// CreateContainer creates a new container in specified PodSandboxrpc CreateContainer(CreateContainerRequest) returns (CreateContainerResponse) {}

// StartContainer starts the container.rpc StartContainer(StartContainerRequest) returns (StartContainerResponse) {}

//提供了从镜像仓库拉取、查看、和移除镜像的RPC。ImageService

// ListImages lists existing images.rpc ListImages(ListImagesRequest) returns (ListImagesResponse) {}

// PullImage pulls an image with authentication config.rpc PullImage(PullImageRequest) returns (PullImageResponse) {}

// ImageFSInfo returns information of the filesystem that is used to store images.rpc ImageFsInfo(ImageFsInfoRequest) returns (ImageFsInfoResponse) {}

注：除非集成了rktnetes，否则CRI都是被默认启用了，kubernetes1.7版本开始旧的预集成的docker CRI已经被移除。

CNI（Container Network Interface）容器网络接口，提供网络资源

cni

Git

CNI接口

设计考量

容器运行时必须在调用任何插件之前为容器创建一个新的网络命名空间。然后，运行时必须确定这个容器应属于哪个网络，并为每个网络确定哪些插件必须被执行。网络配置采用JSON格式。网络配置包括必填字段，如name和type以及插件（类型）。网络配置允许字段在调用之间改变值。为此，有一个可选的字段args，必须包含不同的信息。容器运行时必须按顺序为每个网络执行相应的插件，将容器添加到每个网络中。在完成容器生命周期后，运行时必须以相反的顺序执行插件（相对于执行添加容器的顺序）以将容器与网络断开连接。容器运行时不能为同一容器调用并行操作，但可以为不同的容器调用并行操作。容器运行时必须为容器订阅ADD和DEL操作，这样ADD后面总是跟着相应的DEL。 DEL可能跟着额外的DEL，但是，插件应该允许处理多个DEL（即插件DEL应该是幂等的）。容器必须由ContainerID唯一标识。存储状态的插件应该使用（网络名称，容器ID）的主键来完成。运行时不能调用同一个网络名称或容器ID执行两次ADD（没有相应的DEL）。换句话说，给定的容器ID必须只能添加到特定的网络一次。

三类IP

Node IP：宿主机的IP地址

Pod IP：使用网络插件创建的IP（如flannel），使夸主机的Pod可以互通

Cluster IP：虚拟IP，通过iptables规则访问服务

CNI插件

CNI插件必须实现一个可执行文件，这个文件可以被容器管理系统（例如rkt或Kubernetes）调用，并负责将网络接口插入容器网络命名空间

必须支持操作

将容器添加到网络

从网络中删除容器

IPAM插件

可用插件

网络解析(Flannel)

Flannel是作为一个二进制文件的方式部署在每个node上，主要功能

为每个node分配subnet，容器将自动从该子网中获取IP地址

当有node加入到网络中时，为每个node增加路由配置

网络架构图

CSI（Container Storage Interface）容器存储接口，提供存储资源

略

图