K8s的概念概念|

别裁伪体亲风雅，转益多师是汝师。这篇文章主要讲述K8s的概念相关的知识，希望能为你提供帮助。
?1.?什么是Kubernetes?

Kubernetes是一个全新的基于容器技术的分布式系统支撑平台。
是Google开源的容器集群管理系统(谷歌内部:Borg)。
在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能。

提高了大规模容器集群管理的便捷性。并且具有完备的集群管理能力
多层次的安全防护和准入机制
多租户应用支撑能力
透明的服务注册和发现机制
內建智能负载均衡器
强大的故障发现和自我修复能力
服务滚动升级和在线扩容能力
可扩展的资源自动调度机制
多粒度的资源配额管理能力

?2.master节点?
?k8s集群的管理节点,负责管理集群,提供集群的资源数据访问入口?
?kube-apiserver ?

kubernets api server为api对象验证并配置数据,包括pods,services,replicationcontrollers和其他api对象
api server 提供rest操作和到集群共享状态的前端
所有其他组件通过它进行交互

??https://www.kubernetes.org.cn/doc-30??
?kubernets-scheduler?

kubernets scheduler 是一个拥有丰富策略,能够感知拓扑变化,支持特定负载的功能组件
它对集群的可用性,性能表现以及容量都影响巨大,

#scheduler需要考虑:
- 独立的和集体的资源需求
- 服务质量需求
- 硬件
- 软件
- 策略限制
- 亲和和反亲和规范
- 数据位置
- 内部负载接口
- 截止时间等等
如有必要,特定的负载需求可以通过api暴露出来

?kube-controller-manager?

集群内部的管理控制中心
负责集群内的node,pod副本,服务端点,命名空间,服务账号,资源定额的管理
当某个Node意外宕机时,controller manager会及时发现并执行自动化修复流程,确保集群始终处于预期的工作状态

?etcd?

kubernetes默认的存储系统
保存所有集群数据,使用时需要为etcd数据提供备份计划

??https://github.com/etcd-io/etcd??
?3.node节点?
?kube-proxy?

kubernets网络代理
它反应了node上,kubernetes api中定义的服务,并可以通过一组后端进行简单的tcp ,udp流转发或循环模式的tcp,upd转发;

用户必须使用apiserver api创建一个服务来配置代理,其实就是kube-proxy通过在主机上维护网络规则并执行连接
转发来实现kubernetes服务访问

kube-proxy 运行在所有节点上,它监听apiserver中service和endpoint的变化情况,创建路由规则以提供服务IP
和负载均衡功能。
简单理解此进程是Service的透明代理兼负载均衡器,其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。

kube-proxy iptables原理

Kubernetes从1.2版本开始,将iptables作为kube-proxy的默认模式。
iptables模式下的kube-proxy不再起到Proxy的作用,

其核心功能:通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息,并更新对应的iptables规则,
Client的请求流量则通过iptables的NAT机制"直接路由"到目标Pod。

kube-proxy ipvs原理

IPVS在Kubernetes1.11中升级为GA稳定版。
IPVS则专门用于高性能负载均衡,并使用更高效的数据结构(Hash表),允许几乎无限的规模扩张,
因此被kube-proxy采纳为最新模式

在IPVS模式下,使用iptables的扩展ipset,而不是直接调用iptables来生成规则链。iptables规则链是一
个线性的数据结构,ipset则引入了带索引的数据结构,因此当规则很多时,也可以很高效地查找和匹配。

可以将ipset简单理解为一个IP(段)的集合,这个集合的内容可以是IP地址、IP网段、端口等,
iptables可以直接添加规则对这个"可变的集合"进行操作,这样做的好处在于可以大大减少iptables规则的数量,
从而减少性能损耗。

kube-proxy ipvs和iptables的异同

iptables与IPVS都是基于Netfilter实现的,但因为定位不同,二者有着本质的差别:
iptables是为防火墙而设计的;
IPVS则专门用于高性能负载均衡,并使用更高效的数据结构(Hash表),允许几乎无限的规模扩张。

#与iptables相比,IPVS拥有以下明显优势:
1、为大型集群提供了更好的可扩展性和性能;
2、支持比iptables更复杂的负载均衡算法(最小负载、最少连接、加权等);
3、支持服务器健康检查和连接重试等功能;
4、可以动态修改ipset的集合,即使iptables的规则正在使用这个集合。

?kubelet?

kubelet是主要的节点代理,它会监视已分配给节点的pod
具体功能如下:
- 向master汇报node节点的状态信息
- 返回pod的运行状态
- 准备pod所需的数据卷
- 接受指令并在pod中创建docker容器
- 在node节点执行容器健康检查

?4.service?
??参考?：??https://blog.csdn.net/weixin_43936969/article/details/106169579??

POD 中运行的容器存在动态、弹性的变化（容器的重启IP地址会变化），因此便产生了service，其资源为此类
POD对象提供一个固定、统一的访问接口及负载均衡能力，并借助DNS系统的服务发现功能，解决客户端发现容器
难得问题

service 和POD 对象的IP地址在集群内部可达，但集群外部用户无法接入服务，解决的思路有：

1.在POD上做端口暴露(hostPort)
2.在工作节点上用公用网络名称空间(hostNetwork)
3.使用service 的NodePort 或 loadbalancer （service依赖于DNS资源服务）
4.ingress七层负载均衡和反向代理资源

service 提供pod的负载均衡的能力,但只在4层有负载,而没有功能,只能到IP层面。
?service的几种类型?

1)clusetr IP:默认类型,自动分配一个仅可以在内部访问的虚拟IP,仅供内部访问

2)nodeport:在clusterip的基础上,为集群内的每台物理机绑定一个端口,外网通过任意节点的物理机IP来
访问服务,应用方式: 外服访问服务

3)loadbalance:在nodeport的基础上,提供外部负载均衡与外网统一IP,此IP可以将讲求转发到对应的服务上。
应用方式: 外服访问服务

4)externalname : 引用集群外的服务,可以在集群内部通过别名的方式访问

?ingress?

service 只能提供四层的负载,虽然可以通过nodeport的方式来服务,但随着服务的增多,会在物理机上开辟太多
的端口,不便于管理,所以ingress换了思路来暴露服务

创建一个具有n个副本的nginx服务,在nginx服务内配置各个服务的域名与集群内部的服务的ip,这些nginx服务再
通过nodeport的方式来暴露,外部服务可以通过域名:nginx nodeport端口来访问nginx,nignx再通过域名反向
代理到真实的服务器。

ingress分为ingress controller和ingress 配置。
ingress controller就是反向代理服务器,对外通过nodeport 来暴露端口

service: 主要用来解决pod动态变化时候的IP变化,一旦pod ip变化,客户端就无法找到,service就是来解决这个
问题的。一个service就可以看做一组提供相同服务的pod的对外接口。
service服务于哪些pod是通过标签选择器来定义的。
而且service只能通过四层负载，就是ip+端口的形式来暴露

ingress可以提供7层的负载对外暴露接口,而且可以调度不同的业务域,不同的url访问路径的业务流量。

?5.k8s中的对象objects?
?pod?

k8s中最小部署单元,不是一个程序/进程,而是一个环境(包括:容器,存储,网络Ip,容器配置)
其中可以运行1个或多个container
在一个Pod内部的container共享所有资源,包括共享pod的ip:port和磁盘

pod是临时性的,用完即丢弃的
当pod中的进程结束,node故障,或者资源短缺时,pod会被干掉
所以用户很少直接创建一个独立的pods,而会通过K8s中的controller来对Pod进行管理

controller通过Pod templates来创建Pod,pod template是一个静态模板,创建出来之后的pod就跟模板没有关系了,
模板的修改也不会影响现有的pod

?services?

由于pod是临时性的,pod的ip:port也是动态变化的,这种动态变化在K8s集群中就涉及到一个问题
如果一组后端pod作为服务提供方,供一组前端的pod所调用,那服务调用方怎么自动感知服务提供方,就引入了k8s
中的另一个概念,services

services是通过apiserver创建出来的对象实例
----------------------
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376

这个配置将创建出来一个新的Service对象,名为my-service,后端是所有包含app=MyApp的pod,目标端口是9376,
同时这个service也会被分配一个ip,被称为集群ip,对应的端口是80如果不指定targetPort, 那么targetPort与
port相同

targetPort可以是一个String类型的名字,该名字对应的真实端口值由各个后端pod自己定义,这样同一组pod无需
保证同一个port,更加灵活

?6.Pod?
创建Pod?

#1
用户使用create yaml创建pod,请求给apiseerver,apiserver将yaml中的属性信息(metadata)写入etcd

#2
apiserver触发watch机制准备创建pod,信息转发给调度器(scheduler),调度器使用调度算法选择node,调度器
将node信息给apiserver,apiserver将绑定的node信息写入etcd

#3
apiserver又通过watch机制,调用kubelet,指定pod信息,触发docker run命令创建容器
创建完成之后反馈给kubelet, kubelet又将pod的状态信息给apiserver,
apiserver又将pod的状态信息写入etcd

#其中kubectl get pods命令调用的是etcd_的信息

?Pod可能位于的状态?

Pending:API Server已经创建该Pod,且Pod内还有一个或多个容器的镜像没有创建,包括正在下载镜像的过程
Running:Pod内所有容器均已创建,且至少有一个容器处于运行状态、正在启动状态或正在重启状态
Succeeded: Pod内所有容器均成功执行退出,且不会重启
Failed:Pod内所有容器均已退出,但至少有一个容器退出为失败状态
Unknown:由于某种原因无法获取该Pod状态,可能由于网络通信不畅导致

?Pod的重启策略?

Pod重启策略(RestartPolicy)应用于Pod内的所有容器,并且仅在Pod所处的Node上，由kubelet进行判断和重启操作。
当某个容器异常退出或者健康检查失败时,kubelet将根据RestartPolicy的设置来进行相应操作

Pod的重启策略包括Always、OnFailure和Never,默认值为Always
Always:当容器失效时,由kubelet自动重启该容器
OnFailure: 当容器终止运行且退出码不为0时,由kubelet自动重启该容器
Never:不论容器运行状态如何,kubelet都不会重启该容器

同时Pod的重启策略与控制方式关联,当前可用于管理Pod的控制器包括:
ReplicationController
Job
DaemonSet
kubelet管理(静态Pod)

#不同控制器的重启策略限制如下:
RC和DaemonSet:必须设置为Always,需要保证该容器持续运行;
Job:OnFailure或Never,确保容器执行完成后不再重启;
kubelet:在Pod失效时重启,不论将RestartPolicy设置为何值,也不会对Pod进行健康检查

?静态Pod?

静态pod是由kubelet进行管理的
仅存在于特定Node的Pod上
不能通过API Server进行管理
无法与ReplicationController、Deployment或者DaemonSet进行关联
并且kubelet无法对他们进行健康检查

静态Pod总是由kubelet进行创建,并且总是在kubelet所在的Node上运行。

?Pod的健康检查方式?

对Pod的健康检查可以通过两类探针来检查:LivenessProbe和ReadinessProbe。
#1)LivenessProbe探针:
用于判断容器是否存活(running状态),如果LivenessProbe探针探测到容器不健康,则kubelet将杀掉该容器,并
根据容器的重启策略做相应处理
若一个容器不包含LivenessProbe探针,kubelet认为该容器的LivenessProbe探针返回值用于是"Success"。

#2)ReadineessProbe探针:
用于判断容器是否启动完成(ready状态)。如果ReadinessProbe探针探测到失败,则Pod的状态将被修改。
Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Eenpoint。

#startupProbe探针:
启动检查机制,应用一些启动缓慢的业务,避免业务长时间启动而被上面两类探针kill掉

?LivenessProbe探针的常见方式?

kubelet定期执行LivenessProbe探针来诊断容器的健康状态,通常有以下三种方式:
#1)ExecAction:
在容器内执行一个命令,若返回码为0,则表明容器健康。

#2)TCPSocketAction:
通过容器的IP地址和端口号执行TCP检查,若能建立TCP连接,则表明容器健康。

#3)HTTPGetAction:
通过容器的IP地址、端口号及路径调用HTTP Get方法,若响应的状态码大于等于200且小于400,则表明容器健康。

?Pod的常见调度方式?

Kubernetes中,Pod通常是容器的载体,主要有如下常见调度方式:
#Deployment或RC:
该调度策略主要功能就是自动部署一个容器应用的多份副本,以及持续监控副本的数量,在集群内始终维持用户指定的副本数量。

#NodeSelector:定向调度
当需要手动指定，将Pod调度到特定Node上,可以通过Node的标签(Label)和Pod nodeSelector属性相匹配。

#NodeAffinity亲和性调度:
亲和性调度机制极大的扩展了Pod的调度能力,目前有两种节点亲和力表达:
#1)requiredDuringSchedulingIgnoredDuringExecution:
硬规则,必须满足指定的规则,调度器才可以调度Pod至Node上(类似nodeSelector,语法不同)。
#2)preferredDuringSchedulingIgnoredDuringExecution:
软规则,优先调度至满足的Node的节点,但不强求,多个优先级规则还可以设置权重值。

#Taints和Tolerations(污点和容忍):
Taint:使Node拒绝特定Pod运行;
Toleration:为Pod的属性,表示Pod能容忍(运行)标注了Taint的Node。

?7.相关概念?
?pod?

运行于Node节点上,若干相关容器的组合
Pod内包含的容器运行在同一宿主机上,使用相同的网络命名空间、IP地址和端口,能够通过localhost进行通信。
Pod是Kurbernetes进行创建、调度和管理的最小单位,它提供了比容器更高层次的抽象,使得部署和管理更加灵活。
一个Pod可以包含一个容器或者多个相关容器。

?label?

Kubernetes中的Label实质是一系列的Key/Value键值对,其中key与value可自定义。
Label可以附加到各种资源对象上,如Node、Pod、Service、RC等。
一个资源对象可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象上去。
Kubernetes通过Label Selector(标签选择器)查询和筛选资源对象。

?Replication Controller?

Replication Controller用来管理Pod的副本,保证集群中存在指定数量的Pod副本。
集群中副本的数量大于指定数量,则会停止指定数量之外的多余容器数量。
反之,则会启动少于指定数量个数的容器,保证数量不变。
Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。

RC的机制

Replication Controller用来管理Pod的副本,保证集群中存在指定数量的Pod副本。
当定义了RC并提交至Kubernetes集群中之后,Master节点上的Controller Manager组件获悉,并同时巡检系统中
当前存活的目标Pod,并确保目标Pod实例的数量刚好等于此RC的期望值,若存在过多的Pod副本在运行,系统会停止
一些Pod,反之则自动创建一些Pod。

#简述Kubernetes Replica Set 和 Replication Controller 之间有什么区别？
Replica Set 和 Replication Controller 类似,都是确保在任何给定时间运行指定数量的Pod副本

不同之处:
RS使用基于集合的选择器
Replication Controller使用基于权限的选择器。

?Deployment?

Deployment在内部使用了RS来实现目的,Deployment相当于RC的一次升级,
其最大的特色为可以随时获知当前Pod的部署进度。

?HPA(Horizontal Pod Autoscaler)?

Pod的横向自动扩容,也是Kubernetes的一种资源
通过追踪分析RC控制的所有Pod目标的负载变化情况,来确定是否需要针对性的调整Pod副本数量

?Service?

Service(Kubernetes之服务发现)定义了Pod的逻辑集合和访问该集合的策略,是真实服务的抽象
Service提供了一个统一的服务访问入口以及服务代理和发现机制,关联多个相同Label的Pod,用户不需要了解后台
Pod是如何运行

?Volume?

Volume是Pod中能够被多个容器访问的共享目录
Kubernetes中的Volume是定义在Pod上,可以被一个或多个Pod中的容器挂载到某个目录下

?Namespace?

Namespace用于实现多租户的资源隔离
可将集群内部的资源对象分配到不同的Namespace中,形成逻辑上的不同项目、小组或用户组,便于不同的Namespace
在共享使用整个集群的资源的同时还能被分别管理

【K8s的概念】?8.相关组件?

Kubernetes Master控制组件,调度管理整个系统(集群),包含如下组件:
#Kubernetes API Server:
作为Kubernetes系统的入口,其封装了核心对象的增删改查操作,
以RESTful API接口方式提供给外部客户和内部组件调用,集群内各个功能模块之间数据交互和通信的中心枢纽

#Kubernetes Scheduler:
为新建立的Pod进行节点(node)选择(即分配机器),负责集群的资源调度

#Kubernetes Controller:
负责执行各种控制器,目前已经提供了很多控制器来保证Kubernetes的正常运行

#Replication Controller:
管理维护Replication Controller,关联Replication Controller和Pod,
保证Replication Controller定义的副本数量与实际运行Pod数量一致

#Node Controller:
管理维护Node,定期检查Node的健康状态,标识出(失效|未失效)的Node节点

#Namespace Controller:
管理维护Namespace,定期清理无效的Namespace,包括Namesapce下的API对象,比如Pod、Service等

#Service Controller:
管理维护Service,提供负载以及服务代理

#EndPoints Controller:
管理维护Endpoints,关联Service和Pod,创建Endpoints为Service的后端,
当Pod发生变化时,实时更新Endpoints。

#Service Account Controller:
管理维护Service Account,
为每个Namespace创建默认的Service Account,同时为Service Account创建Service Account Secret。

#Persistent Volume Controller:
管理维护Persistent Volume和Persistent Volume Claim,
为新的Persistent Volume Claim分配Persistent Volume进行绑定,为释放的Persistent Volume执行清理回收。

#Daemon Set Controller:
管理维护Daemon Set,负责创建Daemon Pod,
保证指定的Node上正常的运行Daemon Pod

#Deployment Controller:
管理维护Deployment,关联Deployment和Replication Controller
保证运行指定数量的Pod
当Deployment更新时,控制实现Replication Controller和Pod的更新

#Job Controller:
管理维护Job,为Jod创建一次性任务Pod,保证完成Job指定完成的任务数目

#Pod Autoscaler Controller:
实现Pod的自动伸缩,定时获取监控数据,进行策略匹配,当满足条件时执行Pod的伸缩动作