文章目录
1. Kubernetes简介
1.1 是什么
-
基于容器技术的分布式架构方案,源自谷歌内部的大规模集群管理系统Borg
-
希腊语,领航员;抽象数据a中心的硬件基础设施,对外暴露的是巨大的资源池
1.2 用途
- 单体应用=>微服务:单机=>集群管理,应用内耦合=>不便维护=>拆解服务=>微服务架构;
- 微服务部署难点:环境需求的差异、持续交付的需求=>容器(单容器单进程模型)=>集群资源的自动化管理和大量容器应用的自动化部署
- 核心功能:集中一切资源、提高资源利用率、帮助开发聚焦核心应用(远离服务发现、扩容、基础设施)、健康检查和自我修复、自动扩容、简化部署
2. Kubernetes组件结构与基本概念
2.1 结构
- Master(主节点、控制平面、1-3台物理主机):整个集群的控制节点,以单进程的形式运行多个组件:
- kubernetes API server:提供HTTP Rest接口,集群内增删改查的唯一入口,集群控制的唯一入口
- Kubernetes Controller Manager:所有资源的自动化控制中心
- kubernetes Scheduler:资源调度器,自动化分配pod
- etcd持久化存储服务:存储所有资源对象的数据
- Node(工作节点,一台物理主机):运行一定的工作负载(pod),
- kubelet: 负责pod对应的容器的创建、启停任务;与master协作,实现集群整体的基本管理
- kube-proxy:实现k8s service的通信与负载均衡机制的重要组件
- 容器引擎:docker,负责容器创建和管理
- 除了上述组件的附加组件:
- k8s dns
- dashboard
- Ingress控制器
- Heapster
- CNI插件
- 关于组件
- 单组件多实例:工作节点的组件运行在一台机器上,master节点上的组件除了调度器和controller manager同一时间只能有一个实例起作用外,其余组件可以以单组件多实例并行运行的模式运行在多台机器上
- 组件如何运行:除了kubelet是系统组件,其他组件作为pod运行;可以在kube-system namespace下查看
2.2 核心组件
2.2.1 K8s API server
-
集群数据唯一访问入口
-
安全:HTTPS安全传输与CA签名数字证书强制双向认证
-
RBAC访问控制策略
-
api层(Restful api 接口:get list watch)->访问控制(鉴权、核准访问权)->注册表层(保存所有资源对象,如何创建对象、转换资源不同版本)->etcd数据库(存储kv数据,提供watch接口以实现List Watch机制)
-
此外还有kube proxy api 接口,通过FQDN(全限定域名)转发请求到特定pod、服务,例如:
curl http://master-ip:8080/api/v1/proxy/namespaces/default/pods/my-pod-name/
访问对应的pod
2.2.2 Controller Manager
-
各种资源的Controller通过设置资源的期望状态、watch资源对象事件自动化管理资源对象;controller manager则负责管理这些controller
-
常见的有:replication controller\node controller\resourceQuota controller\namespace controller\service controller\endpoints controller\pv controller
2.2.3 Scheduler调度器
-
负责pod的调度:接收controller要求创建pod的信号,在node list中选取合适的node分配pod,最后由node上的kubelet实际创建管理pod
-
调度流程:
- 预选调度(xxx predicates预选策略选出候选节点):内置多个预选算法,以插件形式注册在系统中;包含资源要求的相互匹配、标签选择是否满足、端口是否被占用、使用卷要求、是否容忍节点污点、是否符合亲缘性非亲缘性要求
- 确定最优节点 (xxx Priority优选策略计算节点积分,选取积分最高的节点)
2.2.4 kubelet
- 注册节点到master
- 管理pod:创建、停止、健康检查(探针)
2.2.5 kubernetes Service Proxy
- 确保对服务ip和端口的某个连接最终会到达某个pod,同时负责负载均衡
- 功能:
- 起初,kube proxy是真实的tcp/udp代理:pod用cluster IP访问某个服务->流量被本机的iptables转发到本机的kube-proxy->kube-proxy建立到后端pod的tcp/udp连接
- 1.2版本后,kube-proxy只负责监听service\endpoints的变更信息,更新iptables,流量则通过iptables的nat机制直接路由到目标pod;相比前一个方式,iptables的转发操作不需要经过kube-proxy,效率更高
- 进一步,iptables规则膨胀后效率降低,目前使用第三种方式,使用IPVS(IP virtual Server)+ipset,IPVS同样基于内核的netfilter(提供网络协议栈上的操作挂载点,在各个阶段放置hook函数,处理、转发、丢弃流量数据)实现,但是ipVS专门用于高性能负载均衡,并且使用hash表,易于扩张。ipset是iptables的扩展(iptables是线性结构,ipset具有索引)
2.3 基本概念
- Master:集群控制节点
- Node:工作节点
- Pod:工作负载的基本单元
- pod内有一个或者多个业务相关的容器
- 结构上,有一个根容器pause容器;业务容器共享pause容器的ip\挂接的卷资源,pause容器的状态与业务容器无关,代表了整个pod的状态(某个具体业务容器的死亡,不能影响整个pod的状态判断,因而采用此结构;所有资源基于pause容器,简化了共享资源时发生的容器通信过程)。
- pod分为静态和动态,静态pod数据不存放在master上,而是放在node上的具体文件中,只存在此node上,无法被调度
- pod中一个容器死亡会重启整个pod;所在的node死亡则重新调度到别的node
- Label:标签,一组键值对,可以标记版本、环境、架构、分区、质量管控、开发阶段;资源对象之间可以通过标签选择器进行相互匹配
- Replication Controller: rc,定义了一个期望场景:
- pod期待的副本数量
- 筛选pod的标签
- 创建、恢复pod的pod template
- 可以通过命令进行pod的滚动升级。
- 已废弃,继任者:replicaSet\depeloyment,rc的命令基本使用于rs,rs标签选择功能更丰富,而deplyment则是更高一级的资源,隐藏管理rs的细节,提供自动化的pod创建、删除、更新的机制
- deplyment
- horizontal pod autoscaler:hpa,pod横向自动扩容,追踪分析rc控制的pod的负载情况,确定是否调整副本数量。
- 指标:cpu平均利用率(已使用/request)、自定义的度量指标(tps,qps)
- StatefulSet:rc,rs,deployment,daemonset、job都是面向无状态的,statefulset是有状态的
- 每个pod都有稳定、唯一的网络标识,例如ss-0,ss-1
- pod的启停顺序受控,操作第n个pod时,前n-1个必然已经是运行且ready的状态
- pod采用持久化存储,删除pod不会删除相关的存储卷(为了数据安全)
- 需要与headless service配合使用,访问其中的pod需要使用唯一的dns域名
- service:服务入口,
- 通过endpoint访问后端的pod
- 服务发现:
- 内部:唯一的cluster IP和service name,通过dns服务访问
- 外部:NodePort、LB
- job:批处理任务,处理work item
- job控制的容器短暂运行,仅运行一次,失败后不重启====>cronJob,定时启动
- 可以多实例并行处理
- namespace:资源隔离,资源可见行
- annotation:注解,kv对,通常可以记辅助信息
- 存储\数据、配置相关:
- Volume:卷,emtpyDir gitrepo h