K8S概念及其常见组件和整体架构
1.概念
-
什么是Kubernetes
-
官网:Kubernetes 文档 | Kubernetes
-
K8S的本质是一组服务器集群,可以在对应服务器集群的每个节点上运行程序,来对节点中的容器进行管理
-
类似Master-Work方式,每个服务器上安装特定的K8S组件,就可以形成集群,然后部署对应的应用即可
-
-
K8S常见的功能
- 服务发现和负载均衡
- Kubernetes可以使用DNS名称或自己的IP地址来暴露容器
- 如果进入容器的流量很大,Kubernetes能够自动实现请求的负载均衡分配网络流量,从而使部署稳定
- 存储编排
- Kubernetes允许自动挂载选择的存储系统,例如本地存储、云提供商存储等
- 自动部署和回滚
- 可以用K8S自动化部署创建新容器,删除现有容器并将它们的所有资源用于新容器
- 当版本发布错误,可以立刻回退到之前的版本
- 自我修复
- 如果某个容器宕机了,K8S可以快速重新启动新的容器,替换旧的容器
- 密钥与配置管理
- K8S允许存储和管理敏感信息,例如密码、OAuth令牌和ssh密钥
- 服务发现和负载均衡
2.K8S常见概念组件
-
K8S整体架构,也是Client-Server模型
- 控制节点Master-Node,负责集群的管理
- 工作节点Worker-Node,负责为集群提供运行环境
-
K8S常见概念
-
Master
- 集群控制节点(相当于整个集群的指挥中心),在每个Kubernetes集群里都需要一个Master来负责整个集群的管理和控制
-
Node
- 除了Master,K8S集群中的其他机器被称为Node节点,Node节点才是Kubernetes集群中的工作负载节点
- 每个Node节点都会被Master分配一些工作负载(docker容器),Node节点上的docker负责容器的运行
-
Pod
- Pod是一组容器,在K8S中最小的单位是Pod,一个Pod可以包含多个容器,但通常情况下我们在每个Pod中仅使用一个容器
- 可以理解成豌豆荚,Pod内的每个容器是一颗颗豌豆
- 分类
- 自主创建:直接创建出来的Pod,这种Pod删除后就没有了,也不会自动重建
- 控制器创建:通过控制器创建的Pod,这类Pod删除了之后还会自动重建
-
Pod Controller
- 控制器是管理Pod的中间层,只需要告诉Pod控制器,想要创建多少个什么样的Pod,它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod在运行中出现故障,它会基于指定策略重新编排Pod
- 通过它来实现对Pod的管理,比如启动Pod、停止Pod、扩展Pod的数量等等
- 类型
- ReplicaSet、Deployment、Horizontal Pod Autoscaler、DaemonSet等
-
Service
- 在K8S里面,每个Pod都会被分配一个单独的IP地址,但这个IP地址会随着Pod的销毁而消失
- Service(服务)就是用来解决这个问题的,对外服务的统一入口,用于为一组提供服务的Pod抽象一个稳定的网络访问地址
- 一个Service可以看作一组提供相同服务的Pod的对外访问接口,作用于哪些Pod是通过标签选择器来定义的
-
Label
- K8S提供了一种机制来为Pod进行分类,那就是Label(标签),同一类Pod会拥有相同的标签
- Label的具体形式是key-value的标记对,可以在创建资源的时候设置,也可以在后期添加和修改
- 给某个资源对象定义一个Label,就相当于给它打了一个标签,可以通过Label Selector(标签选择器)查询和筛选拥有哪些Label的资源对象,K8S通过这种方式实现了类似SQL的对象查询机制
-
Label选择器
- 对应的资源打上标签后,可以使用标签选择器过滤指定的标签
- 标签选择器目前有两个
- 基于等值关系:等于、不等于
- 基于集合关系:属于、不属于、存在
-
NameSpace
- 可以在一个物理集群上运行多个虚拟集群,这种虚拟集群被称为命名空间,用来隔离Pod的运行环境
- 同一个命名空间中的资源名称必须唯一
- NameSpace是不能嵌套的,每一个Kubernetes的资源都只能在一个NameSpace内
- 命名空间是在多个用户之间划分集群资源的一种方法(通过资源配额)
- 不必使用多个命名空间来分隔轻微不同的资源,例如同一软件的不同版本,应该使用标签来区分
- Kubernetes会创建四个初始NameSpace命名空间
- default:没有指明使用其它命名空间的对象所使用的默认命名空间
- kube-system Kubernetes:系统创建对象所使用的命名空间
- kube-public:是自动创建的,命名空间下的资源可以被所有人访问(包括未认证用户)
- kube-node-lease:集群节点之间的心跳维护
-
-
应用分类
- 有状态应用
- 不能简单的实现负载均衡的服务,有数据产生的服务,redis、mysql、rabbitMQ等
- 相关服务需通过一些较复杂的配置才能做到负载均衡
- 有状态的应用,建议直接在物理机部署,方便维护管理
- 无状态应用
- 没有对应业务数据的应用,可以简单的实现负载均衡,复制一个节点即可快速扩容,如SpringCloud中的业务服务
- 无状态的应用适合部署在K8S中或者容器中
- 有状态应用
3.K8S整体架构
-
K8S整体架构,也是Client-Server模型
- 控制节点Master-Node,负责集群的管理
- apiserver:提供操作K8S集群资源的唯一入口,restful方式请求,并提供认证、授权、访问控制、API注册和发现等
- scheduler:负责资源调度,按照预定的调度策略,计算将Pod调度到相应的Node节点进行应用部署
- controller-manager:控制器管理中心,负责维护集群的状态,比如故障检测、滚动更新等,根据调度器的安排通知对应的节点创建Pod
- etcd:存储中心,是兼具一致性和高可用性的键值数据库,可以作为保存Kubernetes所有集群数据的后台数据库
- 工作节点Worker-Node,负责为集群提供运行环境
- Node是Pod真正运行的主机,可以是物理机也可以是虚拟机,Node本质上不是K8S创建的,K8S只是管理Node上的资源,为了管理Pod,每个Node节点上至少需要运行container runtime(Docker)、kubelet和kube-proxy服务
- kubelet:相当于主节点派到工作节点的一个代表,用于管理本机容器(相当于master节点的化身),负责维护容器的生命周期,也负责Volume(CVI)和网络(CNI)的管理
- kube-proxy:负责为Service提供cluster内部的服务发现/网络代理/负载均衡等操作,为部署的应用程序提供访问入口,和apiserver是不一样的,后者是操作K8S集群内部
- 控制节点Master-Node,负责集群的管理
-
架构图