Kubernetes的基础概念

目录

一、Kubernetes的介绍

1、K8S的由来

2、使用K8S的目的

3、K8S的作用

二、Kubernetes的特性

三、K8s集群架构与组件

1、Master组件

2、配置存储中心Etcd

3、Worker Node 组件

3.1 Node节点的工作流程：

docker engine（docker或rocket）

总结

一、Kubernetes的介绍

用于自动部署、扩展和管理"容器化（containerized）应用程序"的开源系统 可以理解成K8S是负责自动化运维管理多个容器化程序（比如Docker）的集群，是一个生态极其丰富的容器编排框架工具

Kubernetes的缩写为：K8S，这个缩写是因为k和s之间有八个字符的关系。

1、K8S的由来

K8S由google的Borg系统(博格系统，google内部使用的大规模容器编排工具)作为原型，后经Go语言延用Borg的思路重写并捐献给CNCF基金会开源。

官网: https://kubernetes.io

GitHub: https://github.com/kubernetes/kubernetes

2、使用K8S的目的

试想下传统的后端部署办法：把程序包（包括可执行二进制文件、配置文件等）放到服务器上，接着运行启动脚本把程序跑起来，同时启动守护脚本定期检查程序运行状态、必要的话重新拉起程序

设想一下，如果服务的请求量上来，已部署的服务响应不过来怎么办?传统的做法往往是，如果请求量、内存、CPU超过阈值做了告警，运维人员马上再加几台服务器，部署好服务之后，接入负载均衡来分担已有服务的压力

这样问题就出现了：从监控告警到部署服务，中间需要人力介入，那么，有没有办法自动完成服务的部署、更新、卸载和扩容、缩容呢?

而这就是K8S要做的事情：自动化运维管理容器(Docker) 程序。K8s的目标是让部署容器化应用简单高效

K8S解决了裸跑Docker的若干痛点：

单机使用，无法有效集群

随着容器数量的.上升，管理成本攀升

没有有效的容灾、自愈机制

没有预设编排模板，无法实现快速、大规模容器调度

没有统一 的配置管理中心工具

没有容器生命周期的管理工具

没有图形化运维管理工具

k8s提供了容器编排，资源调度，弹性伸缩，部署管理，服务发现等一系列功能

3、K8S的作用

用于自动部署、扩展和管理容器化（containerized）应用程序的开源系统。

可以理解成K8S是负责自动化运维管理多个容器化程序（比如docker）的集群，是一个生态机器丰富的容器编排框架工具。

二、Kubernetes的特性

弹性伸缩：使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小成本运行服务。

自我修复：在节点故障时重新启动失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。

服务发现和负载均衡：K8S为多个容器提供一个统一访问入口（内部IP地址和一个DNS名称），并且负载均衡关联的所有容器，使得用户无需考虑容器IP问题。

自动发布（默认滚动发布模式）和回滚：K8S采用滚动策略更新应用，一个更新一个Pod，而不是同时删除所有的Pod，如果更新过程中出现问题，将回滚更改，确保升级不收影响业务。

集中化配置管理和密钥管理：管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性，并可以将一些常用的配置存储在K8S中，方便应用程序使用。

存储编排：支持外挂存储并对外挂存储资源进行编排，挂载外部存储系统，无论是来自本地存储，公有云（如：AWS），还是网络存储（如：NFS、Glusterfs、Ceph）都作为集群资源的一部分使用，极大提高存储使用灵活性。

任务批量处理运行：提供一次性任务，定时任务，满足批量数据处理和分析的场景。

三、K8s集群架构与组件

K8s是属于主从设备模型(Master-Slave 架构)，即有Master 节点负责集群的调度、管理和运维，Slave 节点是集群中的运算工作负载节点。

在K8S中，主节点一般被称为Master 节点，而从节点则被称为Worker Node 节点，每个Node 都会被Master 分配一些工作负载。

Master组件可以在群集中的任何计算机上运行，但建议Master节点占据一个独立的服务器

因为Master是整个集群的大脑，如果Master所在节点宕机或不可用，那么所有的控制命令都将失效

除了Master， 在K8s集群中的其他机器被称为Worker Node节点，当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上去

Kubernetes包含多种类型的资源对象：Pod、 Label、 Service、 Replication Controller 等

所有的资源对象都可以通过Kubernetes 提供的 kubectl工具进行增、删、改、查等操作，并将其保存在etcd中持久化存储

Kubernets其实是一个高度自动化的资源控制系统，通过跟踪对比etcd存储里保存的资源期望状态与当前环境中的实际资源状态的差异，来实现自动控制和自动纠错等高级功能

组件作用

master节点集群控制管理节点，所有的命令都经由master处理

apiserver所有服务的访问入口

controller-manager负责根据预设模板创建pod，维持pod等资源的副本期望数目

scheduler负责调度pod，通过预选策略、优选策略选择最合适的node节点分配pod

etcd分布式键值对数据库，负责存储K8S集群的重要信息（持久化）

work node节点–

Kubelet跟apiserver通信汇报当前node节点上的资源使用情况和状态，接受apiserver的指令跟容器引擎交互实现容器的生命周期管理

Kube-proxy在node节点上实现pod的网络代理，维护网络规则和四层负载均衡规则，负责写入规则到iptables或ipvs实现服务映射访问

容器运行时docker运行容器，负责本机的容器创建和管理工作

1、Master组件

Master：集群控制管理节点，所有的命令都经由master处理

Kube-apiserver

用于暴露Kubernetes API，任何资源请求或调用操作都是通过kube-apiserver提供的接口进行。以HTTP Restful API

提供接口服务，所有对象资源的增删改查和监听操作都交给API Server处理后再提交给Etcd存储

可以理解成API Server 是K8S的请求入口服务。API Server 负责接收K8S所有请求(来自UI界面或者CLI命令行工具)，

然后根据用户的具体请求，去通知其他组件干活。可以说API Server 是K8S集群架构的大脑

Kube-controller-manager

运行管理控制器，是K8S 集群中处理常规任务的后台线程，是K8S集群里所有资源对象的自动化控制中心。

在K8S集群中，一个资源对应一个控制器，而Controller manager就是负责管理这些控制器的

由一系列控制器组成，通过APIServer监控整个集群的状态，并确保集群处于预期的工作状态，比如当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态

这些控制器主要包括:

Node Controller（节点控制器）：负责在节点出现故障时发现和响应

Replication Controller (副本控制器) :负责保证集群中一个RC (资源对 象Replication Controller) 所关联的Pod副本数始终保持预设值。可以理解成确保集群中有且仅有N个Pod实例，N是RC中定义的Pod副本数量

Endpoints Controller（端点控制器）：填充端点对象 (即连接Services 和Pods) ，负责监听 Service 和对应的Pod副本的变化可以理解端点是一个服务暴露出来的访问点，如果需要访问一个服务，则必须知道它的endpoint

Service Account & Token Controllers（服务帐户和令牌控制器）：为新的命名空间创建默认帐户和API访问令牌

ResourceQuota Controller（资源配额控制器）：确保指定的资源对象在任何时候都不会超量占用系统物理资源

Namespace Controller（命名空间控制器）：管理namespace的生命周期

Service Controller（服务控制器）：属于K8S集群与外部的云平台之间的一个接口控制器

Kube-scheduler

是负责资源调度的进程，根据调度算法为新创建的Pod选择一个合适的Node节点

可以理解成K8S所有Node节点的调度器。当用户要部署服务时，Scheduler 会根据调度算法选择最合适的Node 节点来部署Pod

预算策略(predicate)

优选策略( priorities)

2、配置存储中心Etcd

K8S的存储服务

Etcd 是分布式键值存储系统，存储了K8S 的关键配置和用户配置，K8S中仅API Server 才具备读写权限，其他组件必须通过 API Server的接口才能读写数据。

3、Worker Node 组件

3.1 Node节点的工作流程：

Node节点可动态增加到kubernetes集群中，前提是这个节点已经正确安装、配置和启动了上述的关键进程，默认情况下，kubelet会向Master注册自己，这也kubernetes推荐的Node管理方式。

一旦Node被纳入集群管理范围，kubelet会定时向Master汇报自身的情况，以及之前有哪些Pod在运行等，这样Master可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。

如果Node没有按时上报信息，则会被Master判断为失联，Node状态会被标记为Not Ready，随后Master会触发工作负载转移流程。

Kubelet

Node节点的监视器，以及与Master节点的通讯器。Kubelet 是Master节点安插在Node节点上的“眼线”，它会定时向API Server汇报自己

Node节点上运行的服务的状态，并接受来自Master节点的指示采取调整措施

从Master节点获取自己节点上Pod的期望状态(比如运行什么容器、运行的副本数量、网络或者存储如何配置等)，

直接跟容器引擎交互实现容器的生命周期管理，如果自己节点上Pod的状态与期望状态不一致，则调用对应的容器平台接口(即docker的接口)达到这个状态

管理镜像和容器的清理工作，保证节点上镜像不会占满磁盘空间，退出的容器不会占用太多资源

Kube-Proxy

在每个Node节点上实现pod网络代理，是Kubernetes Service 资源的载体，负责维护网络规则和四层负载均衡工作。负责写入规则至iptables、ipvs实现服务映射访问的

Kube-Proxy本身不是直接给Pod 提供网络，Pod的网络是由Kubelet 提供的，Kube-Proxy 实际上维护的是虚拟的Pod集群网络

Kube-apiserver通过监控Kube-Proxy 进行对Kubernetes Service 的更新和端点的维护

在K8S集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8S集群内部的负载均衡器。它是一个分布式代理服务器，在K8S的每个节点上都会运行一个Kube-proxy 组件

docker engine（docker或rocket）

容器引擎，运行容器，负责本机的容器创建和管理工作

总结

K8S有两大节点 master work node

master：apiserver controller-manager scheduler

apiscrvcr：服务访问统一入口

controller(肯邱no)-manager：维持Pod副本期望数目

scheduler(千紧no)：调度Pod资源,选择适合的node分配pod

etcd：分布式数据库，键值对存储方式，持久化存储K8s集群元信息

work node：kubelet kube-proxy docker Engine（容器节点）

kubelet：跟容器引擎交互实现容器的生命周期管理，监控node上节点资源使用情况并向master的apiserver汇报资源使用情况

kube-proxy：实现4层代理，负责写入iptables/ipvs规则实现 service 的映射访问