一.k8s概述

2.为什么要用K8S

3.作用及功能

4.k8s容器集群管理系统

二.K8S的特性

1.弹性伸缩

2.自我修复

3.服务发现和复制均衡

4.自动发布和回滚

5.集中化配置管理和秘钥管理

6.存储编排

7.任务批量处理运行

三.K8S的集群架构

四.K8S的核心组件

1.Master组件

（2）Kube-controller-manager

（3）Kube-scheduler

2.配置存储中心etcd

（2）Kube-Proxy

（3）docker或rocker

4.K8S三种负载均衡模式

5.K8S的架构及工作流程

6.K8S的核心概念

（1）Pod

（2）Pod控制器

7.Label标签

8.Label选择器(Label selector)

9.Service

10.Ingress

11.name

12.Namespace

总结：

1.控制器大类总结

一.k8s概述

（1）K8S全程为Kubernetes，由于K到S直接有8个字母简称为K8S。

（2）版本：目前一般是1.18~1.2.0，后续可能会到1.24-1.26，1.24版本后丢弃了docker(如需要使用需要第三方插件配合)，目前最新版本是1.27

（3）官网：https://kubernetes.io

GitHub：GitHub - kubernetes/kubernetes: Production-Grade Container Scheduling and Management

2.为什么要用K8S

（1）试想下传统的后端部署办法:把程序包(包括可执行二进制文件、配置文件等)放到服务器上，接着运行启动脚本把程序跑起来，同时启动守护脚本定期检查程序运行状态、必要的话重新拉起程序。
（2）设想一下，如果服务的请求量上来，已部署的服务响应不过来怎么办?传统的做法往往是，如果请求量、内存、CPu超过阈值做了告警，运维人员马上再加几台服务器，部署好服务之后，接入负载均衡来分担已有服务的压力。
（3）这样问题就出现了:从监控告警到部署服务，中间需要人力介入!那么，有没有办法自动完成服务的部署、更新、卸载和扩容、缩容呢，而这就是K8S要做的事情:自动化运维管理容器化(Docker) 程序。
（4）解决了docker的以下个问题

●单机使用，无法有效集群
●随着容器数量的上升，管理成本攀升
●没有有效的容灾、自愈机制
●没有预设编排模板，无法实现快速、大规模容器调度
●没有统一的配置管理中心工具
●没有容器生命周期的管理工具
●没有图形化运维管理工具

总：大量访问请求访问不用加机器即可解决大量访问请求，降低成本；并且可以多台建立集群，会将挂的容器剔除前创建新的容器；多个快速部署。

3.作用及功能

（1）作用：用于自动部署、扩展、管理编排容器化应用程序。

（2）功能：容器编排、资源调度、弹性伸缩、部署管理、服务发现等。

4.k8s容器集群管理系统

在Docker等容器技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性其主要功能如下:

使用 Docker等容器技术对应用程序包装 (package)实例化 (instantiate) 、运行 (run)。
以集群的方式运行、管理跨机器的容器。
解决 Docker 跨机器容器之间的通讯问题。
K8S 的自我修复机制使得容器集群总是运行在用户期望的状态

二.K8S的特性

1.弹性伸缩

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

总：根据具体设置的机器数量，自动扩大或缩小（等业务结束）

2.自我修复

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

总：如果其中一台容器挂掉了，k8s会自动生成一模一样的容器，根据前面必须会有的副本数量，得恢复正常的固定几台

3.服务发现和复制均衡

为多容器提供同一的访问入口(内部ip地址和一个dns名称)，并且负载均衡关联所有容器，用户无需考虑容器ip问题

总：新创建的话是根据标签创建的，不会根据IP地址，因为创建的会不一样

4.自动发布和回滚

默认是滚动发布模式(其他二种发布模式，蓝绿发布、灰度发布)。采用滚动更新策略更新应用，一次更新一个Pod而不是同时删除所有Pod如果更新过程中有问题可以回滚更改确保业务升级不受影响

总：一次更新一个Pod而不是同时删除所有Pod如果更新过程中有问题可以回滚更改确保业务升级不受影响

5.集中化配置管理和秘钥管理

管理机密数据和应用程序配置，而不是把敏感数据暴露在镜像中，提高敏感数据安全性、可以将一些常用的配置存储在k8s中，方便应用程序使用

6.存储编排

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

7.任务批量处理运行

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

三.K8S的集群架构

1、K8S是属于主从设备模型(master-slave架构)，master负责集群的调度管理和运维，slave节点是集群中运算工作负载节点，企业中一般最少2台master，多数为3台作为负载。

2、主节点成为master节点，从节点成为worker node节点。每个node都会被master分配任务。

3、master可以在任何集群中的计算机上运行，建议给master一台独立的服务器防止master出问题所有控制命令都将实现，worker node节点宕机该机器上的任务会被自动转移其他节点继续运行。

四.K8S的核心组件

1.Master组件

统一请求入口服务组件，所有资源请求或者调用都通过Kube-apiserver入口提供的接口进行，以Http Restful API 提供接口服务，所有对资源的增删改查和监听都交给APIserver处理，然后再交给ETCD存储(键值对存储方式，相当于分布式数据库)。APIserver负责接受所有请求(uI和CLI)，然后根据用户具体请求通知其他组件干活，APIserver相当于K8S的大脑。

总：集群统一入口，以restful方式交给etcd存储（k8s内所有的日志存储），根据用户请求，通知其他组件干活

（2）Kube-controller-manager

运行管理控制器由各种控制器组成，处理常规任务的后台线程，所有资源对象的自动化控制中心。在K8S中一个资源对应一个控制器，controller-manager负责管理这些控制器，通过API server监控整个集群的状态，确保集群处于预期的工作状态，当某个node意外宕机，controlle-manager会及时发现并自动化修复，确保集群处于预期的工作状态。

总：处理集群中常规的后台任务，一个资源对应一个控制器处理后台集群

控制器	控制名称	控制器作用
Node Controller	节点控制器	负责在节点出现故障时发送和响应
Replication Controller	副本控制器	负责保证集群中一个RC即资源对象所关联的Pod副本数据始终保持预期值
Endpoints Controller	端点控制器	填充端点对象(service和Pods)，负责监听service和对应的Pod副本的变化，服务暴露出来的访问点，如果需要访问一个服务必须知道他都Endpoints
Service Account & Tocken Controller	服务账户和令牌控制器	为新的命名空间创建默认账户和API访问令牌
ResourceQuota Controller	资源配额控制器	确保指定的资源对象在任何时候都不会超量占用系统物理资源
Namespace Controller	命名空间控制器	管理namespace的生命周期
Service Controller	服务器控制器	属于K8S集群与外部云平台之间的一个接口控制器

（3）Kube-scheduler

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

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

预选策略(predicate)：首选过滤掉资源不满足的node

优选策略(priorities)：预选后的满足的节点进行打分排名选择最优的node

总：负责调度pod，通过预先策略，优先策略选择合适的node

2.配置存储中心etcd

etcd：K8s的存储服务，是分布式键值存储系统，最少三台最优为8G内存。存储了K8S的关键配置和用户配置并且持久化保存，K8s中仅有API server才具有读写权限，其他组件必须通过API server的接口才能读写数据。端口为2379和2380,2379用于对外客户的提供通信，2380用于对集群服务器间内部的通信。

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

etcd的大小最好是8G

（2）Kube-Proxy

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

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

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

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

总：在node节点实现pod网络代理，维护网络规则和4层负载均衡工作，负责写入规则到iptables或ipvs实现服务的映射访问

（3）docker或rocker

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

总：负责本机的容器，创建和管工作

4.K8S三种负载均衡模式

（1）namespace

（2）iptables——默认使用

（3）ipvs——此模式更快，所有安装是需要更改为此模式。内核运行更快，性能更好。

5.K8S的架构及工作流程

（1）运维人员操作Kubectl命令向API server发送任务请求，先到Auth进行鉴权认证，然后进到API Server中，API Server存储操作到Etcd

（2）然后API Server根据Etcd中用户执行的操作调用 controller manager对应的控制器进行操作，例如创建

（1）运维人员操作Kubectl命令向API server发送任务请求，先到Auth进行鉴权认证，然后进到API Server中，API Server存储操作到Etcd

（2）然后API Server根据Etcd中用户执行的操作调用 controller manager对应的控制器进行操作，例如创建

运维人员使用kubectl命令发送任务请求到API Server，经过鉴权认证。
API Server将任务请求存储到Etcd中。
Controller Manager根据请求调用相应控制器进行操作，如创建副本集。
Scheduler选择合适的节点，并通过API Server的Kubelet在节点上创建Pod。
Kube-Proxy代理对外映射端口信息，实现负载均衡。
通过Label标签访问容器。

6.K8S的核心概念

包含：Pod、Label、Service、Replication、Controller。等

（1）Pod

是K8s创建或者部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程，Pod里面可以放很多容器。一个Pod由一个或多个容器组成，Pod中的容器共享网络、存储和计算资源在同一台Docker主机上运行，一个Pod可以运行多个容器，又称为边车模式(sidecar)。生产中一般一个Pod就一个容器或者是有多个强关联性互补的容器

同一个Pod直接的容器可以通过localhost互相访问，并且可以挂载Pod内所有数据卷。不同Pod之间的容器不能用localhost访问，也不能挂载Pod内所有数据卷。

（2）Pod控制器

Pod控制器是启动Pod的一种模板，用来保证在K8S里启动Pod应始终按照用户的预期运行（副本数、生命周期（（是否存活）、健康状态检查）
k8s内提供了众多的pod控制器，常用的有以下几种
①Deployment：无状态应用部署即无论谁来访问都是一样的例如http网页
有状态协议：需要持久化

有状态的协议可以安装的服务例如：mysql，但一般建议不安装到k8s中，效率会慢，数据量大，可以放在云上

无状态协议：一次性的不需要持久化，每一次请求都是一条新的数据

无状态的协议可以安装的服务例如：nginx

②Replicaset：受控于Deployment，确保预期的Pod副本数量，Replicaset的通就是管理和控制Pod管理他们好好工作，若发现某个Pod不行了就找个新的Pod来做替换。

控制副本数量，保证一直是固定的数量

③Daemonset：确保所有节点运行同一类Pod，保证每个节点上都有一一个此类Pod运行，通常用于实现系统级后台任务。

Daemonset可以安装的服务例如：zabbix、filebeat，适用于监控和日志收集

④Statefulset：有状态应用部署

可以安装mysql数据库，但一般建议不安装到k8s中，效率会慢，数据量大，可以放在云上

⑤Job：一次性任务。根据用户的设置，Job 管理的Pod把任务成功完成就自动退出了。
⑥Cronjob：周期性计划性任务

总：k8s跑无状态，微服务以及其他中间件比较多

7.Label标签

1）标签是K8s特色的管理方式便于分类管理资源对象

（2）label可以附加到各种资源对象上，例如：node、Pod、service、Rc等，用于关联对象、查询和筛选

（3）一个label是一个key-value的键值对，key-value都由用户自定义

（4）一个资源对象可以定义任意数量的label，同一个label也可以被添加到任意数量的资源对象中，也可以在对象创建后动态添加或者删除

（5）可以通过给指定的资源对象捆绑一个或多个不通的label，实现多维度的资源分组管理功能

8.Label选择器(Label selector)

（1）给某个资源对象定义一个Label，就相当于给他打开了一个标签，随后可以通过标签选择器(Labelselector)查询和筛选拥有某些Label的资源对象。
（2）标签选择器目前有两种:基于等值关系(等于、不等于)和基于集合关系(属于、不属于、存在。

9.Service

（1）概念 K8S集群中每个Pod会被分配一个单独的ip地址，但是由于Pod是有生命周期的(可以被创建而且销毁后不会再重启)，随时可能会因为业务ip的变更，导致这个ip地址会随着Pod的销毁而消失

（2）Service就是用来解决这个问题的核心概念：

Service：通过标签选择器关联具有对应Lable的Pod，再把相关的Pod
IP加入自己的Endpoints当中，service根据Endpoints里的Ip进行转发

不是服务的含义，更像是一个网关层、流量均衡器、Service作用于那些Pod由标签选择器来定义。

service可以看作一组提供相同服务的Pod的对外访问接口，客户端需要访问的服务就是Service的对象，每个Service都有一个虚拟的ip，会自动向后端做转发。

（3）负载均衡功能：自动把请求流量分配到后端所有的服务上，可以对客户端透明的做水平扩展，实现此功能的关键是Kube-proxy，Kubeproxy运行在每个节点上监听APIserver中服务对象的变化，

三种流量调度模式：userspace、iptables(利用的nat默认但不常用、从上往下，慢)、ipvs(推荐，性能最好、通过VIP地址直接转发到后端)，实现网络的转发

Service是K8s服务的核心，屏蔽了服务细节，统一了对外暴露服务接口，真正做到了微服务。用户只需要关注一个Service入口即可，不需要关注具体请求那个Pod。用户不会感知因为Pod上服务的意外崩溃K8S重新拉起Pod而导致的ip变更，也不会感知到因服务升级、服务变更等带来的Pod替换而导致的IP变化。

10.Ingress

service负责K8s集群内部的网络拓扑(四层)、Ingress 是 K8S 集群里工作在 OSI 网络参考模型下，第7层的应用，对外暴露的接口，典型的访问方式是 http/httpsService 只能进行第四层的流量调度，表现形式是 otpot。Tnores 则可以调度不同业各域、不同uRL访问路径的业条流量比如: 客户端请求 http://www.kqc.com;port——Ingress——Service—— Pod (nginx )

11.name

由于 K8S 内部，使用“资源”来定义每一种逻辑概念(功能)，所以每种资源”，都应该有自己的“名称”。"资源”有 api 版木 (apiversion)、类别 (kind)、元数据(metadata)、定义清单(spec)、状态(status)等配置信息。
"名称”通常定义在“资源”的“元数据”信息里。在同一个 namespace 空间中必须是唯一的。

12.Namespace

随着项日增多、人员增加、集群规模的扩大，需要一种能够逻辑上隔离 K8S 内各种“资源”的方法，这就是 amespace.
Namespace 是为了把一个 K8S 集群划分为若干个资源不可共享的虚拟集群组而诞生的。
不同 Namespace 内的“资源”名称可以相同，相同 Naespace 内的同种“资源”，"名称”不能相同。
合理的使用 K8S 的 amespace，可以使得集群管理员能够更好的对交付到 K8S 里的服务进行分类管理和浏览.
K8s 里默认存在的 Namespace 有: default、kube-system、kube-public 等。
查询 K8S 里特定“资源” 要带上相应的 Namnespace。

总结：

1.控制器大类总结

（1）节点控制器
（2）副本控制器
（3）端点控制器
（4）服务账户和令牌控制器
（5）资源配额控制制器
（6）命令空间控制器
（7）服务控制器

2.控制器有五大类
（1）标签选择器 label
给某个资源对象定义一个名称(标签) 相当于给资源打一个标签，能够让service找到相应资源
（2）service
四层，通过四层cluster IP 转发(通过标签进行转发)给 pod 资源
调度方式有三种：usersapce、iptables (默认)、ipvs （推荐性能好）来实现网络的转发
endpoint：自动发现这些pod IPservice 再把IP地址加入到配置当中进行动态转发。

是通过标签选择器关联具有对有label的pod。再把相关pod的IP加入到自己的endpoints当中，service再根据endpoints里的IP进行转发

（3）ingress
通过七层转发给四层的service IP + port
根据业务对应cluster IP
（4）name
是定义资源一种逻辑概念 (功能) k8s内部
资源有哪些：api 版本、kind 类别、metadata 元数据信息、spec 清单、status 状态
（5）namespace
命名空间 k8s 集群划分为若干个资源不可共享的虚拟集群组而诞生的