kubernetes概览

#kubernetes

本文是学习《Kubernetes Handbook》的读书笔记, 对学习kubernetes过程中认为比较重要的概念和一些关键要点进行汇总,以便后续的扩展学习和持续消化。

1. 架构

Kubernetes是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制。

Kubernetes集群包含有节点代理kubelet和Master组件(APIs, scheduler, etc),一切都基于分布式的存储系统。

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

组件 说明
etcd 保存了整个集群的状态;所有master的持续状态都存在etcd的一个实例中
api-server 提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制;这个服务试图通过把所有或者大部分的业务逻辑放到部件中从而使其具有CRUD特性。它主要处理REST操作,在etcd中验证更新这些对象(并最终存储)。
controller manager 负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;所有其它的集群级别的功能目前都是由控制管理器所负责。例如,端点对象是被端点控制器来创建和更新。这些最终可以被分隔成不同的部件来让它们独自的可插拔。replicationcontroller(PS:官方 英文)是一种建立于简单的 pod API之上的一种机制。
scheduler 负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上;
kubelet 负责维护容器的生命周期,同时也负责Volume(CVI)和网络(CNI)的管理;负责管理pods和它们上面的容器,images镜像、volumes、etc。
Container runtime 负责镜像管理以及Pod和容器的真正运行(CRI);
kube-proxy 负责为Service提供cluster内部的服务发现和负载均衡;每一个节点也运行一个简单的网络代理和负载均衡,https://github.com/kubernetes/kubernetes/wiki/Services-FAQ

除了核心组件,还有一些推荐的Add-ons:

组件 说明
kube-dns 负责为整个集群提供DNS服务
Ingress Controller 为服务提供外网入口
Heapster 提供资源监控
Dashboard 提供GUI
Federation 提供跨可用区的集群
Fluentd-elasticsearch 提供集群日志采集、存储与查询

Kubernetes设计理念和功能其实就是一个类似Linux的分层架构:

  • 核心层:Kubernetes最核心的功能,对外提供API构建高层的应用,对内提供插件式应用执行环境
  • 应用层:部署(无状态应用、有状态应用、批处理任务、集群应用等)和路由(服务发现、DNS解析等)
  • 管理层:系统度量(如基础设施、容器和网络的度量),自动化(如自动扩展、动态Provision等)以及策略管理(RBAC、Quota、PSP、NetworkPolicy等)
  • 接口层:kubectl命令行工具、客户端SDK以及集群联邦
  • 生态系统:在接口层之上的庞大容器集群管理调度的生态系统,可以划分为两个范畴
  • Kubernetes外部:日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
  • Kubernetes内部:CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

see: https://www.kubernetes.org.cn/kubernetes%E8%AE%BE%E8%AE%A1%E6%9E%B6%E6%9E%84

2. API

2.1 API设计原则

API设计原则:

  • 所有API应该是声明式的。
  • API对象是彼此互补而且可组合的。
  • 高层API以操作意图为基础设计。
  • 低层API根据高层API的控制需要设计。
  • 尽量避免简单封装,不要有在外部API无法显式知道的内部隐藏的机制。
  • API操作复杂度与对象数量成正比。
  • API对象状态不能依赖于网络连接状态。
  • 尽量避免让操作机制依赖于全局状态,因为在分布式系统中要保证全局状态的同步是非常困难的。

2.2 API对象属性

每个API对象都有3大类属性:元数据metadata、规范spec和状态status。

  • 元数据是用来标识API对象的,每个对象都至少有3个元数据:namespace,name和uid;除此以外还有各种各样的标签labels用来标识和匹配不同的对象,例如用户可以用标签env来标识区分不同的服务部署环境,分别用env=dev、env=testing、env=production来标识开发、测试、生产的不同服务。
  • 规范描述了用户期望K8s集群中的分布式系统达到的理想状态(Desired State),例如用户可以通过复制控制器Replication Controller设置期望的Pod副本数为3;
  • status描述了系统实际当前达到的状态(Status),例如系统当前实际的Pod副本数为2;那么复制控制器当前的程序逻辑就是自动启动新的Pod,争取达到副本数为3。

K8s中所有的配置都是通过API对象的spec去设置的,也就是用户通过配置系统的理想状态来改变系统,这是k8s重要设计理念之一, 即所有的操作都是声明式(Declarative)的而不是命令式(Imperative)的。 声明式操作在分布式系统中的好处是稳定,不怕丢操作或运行多次,例如设置副本数为3的操作运行多次也还是一个结果,而给副本数加1的操作就不是声明式的,运行多次结果就错了。

see: https://www.kubernetes.org.cn/kubernetes%E8%AE%BE%E8%AE%A1%E7%90%86%E5%BF%B5

3. 服务对象

3.1 Pod

Pod是在K8s集群中运行部署应用或服务的最小单元,它是可以支持多容器的。 Pod是一个逻辑组,多个容器可以共享一个Pod中的网络地址和文件系统,可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

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

3.2 复制控制器(Replication Controller,RC)

RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。 少于指定数目,RC就会启动运行新的Pod副本;多于指定数目,RC就会杀死多余的Pod副本。 即使在指定数目为1的情况下,通过RC运行Pod也比直接运行Pod更明智,因为RC也可以发挥它高可用的能力,保证永远有1个Pod在运行。 RC是K8s较早期的技术概念,只适用于长期伺服型的业务类型,比如控制小机器人提供高可用的Web服务。

3.3 副本集(Replica Set,RS)

RS是新一代RC,提供同样的高可用能力,区别主要在于RS后来居上,能支持更多种类的匹配模式。 副本集对象一般不单独使用,而是作为Deployment的理想状态参数使用。

3.4 部署(Deployment)

部署表示用户对K8s集群的一次更新操作。 部署是一个比RS应用模式更广的API对象,可以是创建一个新的服务,更新一个新的服务,也可以是滚动升级一个服务。 滚动升级一个服务,实际是创建一个新的RS,然后逐渐将新RS中副本数增加到理想状态,将旧RS中的副本数减小到0的复合操作; 这样一个复合操作用一个RS是不太好描述的,所以用一个更通用的Deployment来描述。 以K8s的发展方向,未来对所有长期伺服型的的业务的管理,都会通过Deployment来管理。

3.5 服务(Service)

RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量,但是没有解决如何访问这些服务的问题。 一个Pod只是一个运行服务的实例,随时可能在一个节点上停止,在另一个节点以一个新的IP启动一个新的Pod,因此不能以确定的IP和端口号提供服务。 要稳定地提供服务需要服务发现和负载均衡能力。 服务发现完成的工作,是针对客户端访问的服务,找到对应的的后端服务实例。 在K8s集群中,客户端需要访问的服务就是Service对象。 每个Service会对应一个集群内部有效的虚拟IP,集群内部通过虚拟IP访问一个服务。 在K8s集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。 它是一个分布式代理服务器,在K8s的每个节点上都有一个; 这一设计体现了它的伸缩性优势,需要访问服务的节点越多,提供负载均衡能力的Kube-proxy就越多,高可用节点也随之增多。 与之相比,我们平时在服务器端做个反向代理做负载均衡,还要进一步解决反向代理的负载均衡和高可用问题。

  • ClusterIP: 使用集群内的私有ip —— 这是默认值。clusterIP主要在每个node节点使用iptables,将发向clusterIP对应端口的数据,转发到kube-proxy中。然后kube-proxy自己内部实现有负载均衡的方法,并可以查询到这个service下对应pod的地址和端口,进而把数据转发给对应的pod的地址和端口。
  • NodePort: 除了使用cluster ip外,nodePort在node上开了一个端口,将向该端口的流量导入到kube-proxy,然后由kube-proxy进一步导给对应的pod。
  • LoadBalancer: 使用一个ClusterIP & NodePort,但是会向cloud provider申请映射到service本身的负载均衡。
  • ExternalName: 通过CNAME将service与externalName的值(比如:foo.bar.example.com)映射起来. 要求kube-dns的版本为1.7或以上.

k8s的各种ip的关系:

3.6 任务(Job)

Job是K8s用来控制批处理型任务的API对象。 批处理业务与长期伺服业务的主要区别是批处理业务的运行有头有尾,而长期伺服业务在用户不停止的情况下永远运行。 Job管理的Pod根据用户的设置把任务成功完成就自动退出了。 成功完成的标志根据不同的spec.completions策略而不同:

  • 单Pod型任务有一个Pod成功就标志完成;
  • 定数成功型任务保证有N个任务全部成功;
  • 工作队列型任务根据应用确认的全局成功而标志成功。

3.7 后台支撑服务集(DaemonSet)

长期伺服型和批处理型服务的核心在业务应用,可能有些节点运行多个同类业务的Pod,有些节点上又没有这类Pod运行; 而后台支撑型服务的核心关注点在K8s集群中的节点(物理机或虚拟机),要保证每个节点上都有一个此类Pod运行。 节点可能是所有集群节点也可能是通过nodeSelector选定的一些特定节点。典型的后台支撑型服务包括,存储,日志和监控等在每个节点上支持K8s集群运行的服务。

3.8 有状态服务集(PetSet)

RC和RS主要是控制提供无状态服务的,其所控制的Pod的名字是随机设置的, 一个Pod出故障了就被丢弃掉,在另一个地方重启一个新的Pod,名字变了、名字和启动在哪儿都不重要,重要的只是Pod总数; 而PetSet是用来控制有状态服务,PetSet中的每个Pod的名字都是事先确定的,不能更改。

对于RC和RS中的Pod,一般不挂载存储或者挂载共享存储,保存的是所有Pod共享的状态,Pod像牲畜一样没有分别(这似乎也确实意味着失去了人性特征); 对于PetSet中的Pod,每个Pod挂载自己独立的存储,如果一个Pod出现故障,从其他节点启动一个同样名字的Pod,要挂载上原来Pod的存储继续以它的状态提供服务。

适合于PetSet的业务包括数据库服务MySQL和PostgreSQL,集群化管理服务Zookeeper、etcd等有状态服务。 PetSet的另一种典型应用场景是作为一种比普通容器更稳定可靠的模拟虚拟机的机制。 传统的虚拟机正是一种有状态的宠物,运维人员需要不断地维护它,容器刚开始流行时,我们用容器来模拟虚拟机使用,所有状态都保存在容器里,而这已被证明是非常不安全、不可靠的。 使用PetSet,Pod仍然可以通过漂移到不同节点提供高可用,而存储也可以通过外挂的存储来提供高可靠性, PetSet做的只是将确定的Pod与确定的存储关联起来保证状态的连续性。 PetSet还只在Alpha阶段,后面的设计如何演变,我们还要继续观察。

3.9 集群联邦(Federation)

在云计算环境中,服务的作用距离范围从近到远一般可以有: 同主机(Host,Node)、跨主机同可用区(Available Zone)、跨可用区同地区(Region)、跨地区同服务商(Cloud Service Provider)、跨云平台。 K8s的设计定位是单一集群在同一个地域内,因为同一个地区的网络性能才能满足K8s的调度和计算存储连接要求。 而联合集群服务就是为提供跨Region跨服务商K8s集群服务而设计的。

每个K8s Federation有自己的分布式存储、API Server和Controller Manager。 用户可以通过Federation的API Server注册该Federation的成员K8s Cluster。 当用户通过Federation的API Server创建、更改API对象时,Federation API Server会在自己所有注册的子K8s Cluster都创建一份对应的API对象。 在提供业务请求服务时,K8s Federation会先在自己的各个子Cluster之间做负载均衡, 而对于发送到某个具体K8s Cluster的业务请求,会依照这个K8s Cluster独立提供服务时一样的调度模式去做K8s Cluster内部的负载均衡。 而Cluster之间的负载均衡是通过域名服务的负载均衡来实现的。

所有的设计都尽量不影响K8s Cluster现有的工作机制,这样对于每个子K8s集群来说,并不需要更外层的有一个K8s Federation, 也就是意味着所有现有的K8s代码和机制不需要因为Federation功能有任何变化。

3.10 存储卷(Volume)

K8s集群中的存储卷跟Docker的存储卷有些类似,只不过Docker的存储卷作用范围为一个容器,而K8s的存储卷的生命周期和作用范围是一个Pod。 每个Pod中声明的存储卷由Pod中的所有容器共享。 K8s支持非常多的存储卷类型,特别的,支持多种公有云平台的存储,包括AWS,Google和Azure云; 支持多种分布式存储包括GlusterFS和Ceph; 也支持较容易使用的主机本地目录hostPath和NFS。 K8s还支持使用Persistent Volume Claim即PVC这种逻辑存储,使用这种存储,使得存储的使用者可以忽略后台的实际存储技术(例如AWS,Google或GlusterFS和Ceph), 而将有关存储实际技术的配置交给存储管理员通过Persistent Volume来配置。

3.11 持久存储卷(Persistent Volume,PV)和持久存储卷声明(Persistent Volume Claim,PVC)

PV和PVC使得K8s集群具备了存储的逻辑抽象能力,使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置,而把这项配置的工作交给PV的配置者,即集群的管理者。 存储的PV和PVC的这种关系,跟计算的Node和Pod的关系是非常类似的; PV和Node是资源的提供者,根据集群的基础设施变化而变化,由K8s集群管理员配置; 而PVC和Pod是资源的使用者,根据业务服务的需求变化而变化,由K8s集群的使用者即服务的管理员来配置。

3.12 节点(Node)

K8s集群中的计算能力由Node提供,最初Node称为服务节点Minion,后来改名为Node。 K8s集群中的Node也就等同于Mesos集群中的Slave节点,是所有Pod运行所在的工作主机,可以是物理机也可以是虚拟机。 不论是物理机还是虚拟机,工作主机的统一特征是上面要运行kubelet管理节点上运行的容器。

3.13 密钥对象(Secret)

Secret是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。 使用Secret的好处是可以避免把敏感信息明文写在配置文件里。 在K8s集群中配置和使用服务不可避免的要用到各种敏感信息实现登录、认证等功能,例如访问AWS存储的用户名密码。 为了避免将类似的敏感信息明文写在所有需要使用的配置文件中,可以将这些信息存入一个Secret对象,而在配置文件中通过Secret对象引用这些敏感信息。 这种方式的好处包括:意图明确,避免重复,减少暴漏机会。

3.14 用户帐户(User Account)和服务帐户(Service Account)

顾名思义,用户帐户为人提供账户标识,而服务账户为计算机进程和K8s集群中运行的Pod提供账户标识。 用户帐户和服务帐户的一个区别是作用范围;用户帐户对应的是人的身份,人的身份与服务的namespace无关,所以用户账户是跨namespace的; 而服务帐户对应的是一个运行中程序的身份,与特定namespace是相关的。

3.15 名字空间(Namespace)

名字空间为K8s集群提供虚拟的隔离作用,K8s集群初始有两个名字空间,分别是默认名字空间default和系统名字空间kube-system,除此以外,管理员可以可以创建新的名字空间满足需要。

3.16 RBAC访问授权

K8s基于角色的访问控制(Role-based Access Control,RBAC)的授权模式。 RBAC主要是引入了角色(Role)和角色绑定(RoleBinding)的抽象概念。 在ABAC中,K8s集群中的访问策略只能跟用户直接关联;而在RBAC中,访问策略可以跟某个角色关联,具体的用户在跟一个或多个角色相关联。 显然,RBAC像其他新功能一样,每次引入新功能,都会引入新的API对象,从而引入新的概念抽象,而这一新的概念抽象一定会使集群服务管理和使用更容易扩展和重用。

07 Mar 2018,望哥