✅P341_k8s-架构原理与核心概念
架构
整体主从方式
Master 节点架构
kube-apiserver
- 对外暴露 K8S 的 api 接口，是外界进行资源操作的唯一入口
- 提供认证、授权、访问控制、API 注册和发现等机制
etcd
- etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。
- Kubernetes 集群的 etcd 数据库通常需要有个备份计划
kube-scheduler
- 主节点上的组件，该组件监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行。
- 所有对 k8s 的集群操作，都必须经过主节点进行调度
kube-controller-manager
- 在主节点上运行控制器的组件
- 这些控制器包括:
- 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应。
- 副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod。
- 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service与 Pod)。
- 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌
Node 节点架构
kubelet
- 一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。
- 负责维护容器的生命周期，同时也负责 Volume（CSI）和网络（CNI）的管理；
kube-proxy
- 负责为 Service 提供 cluster 内部的服务发现和负载均衡；
容器运行环境(Container Runtime)
- 容器运行环境是负责运行容器的软件。
- Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)。
fluentd
- 是一个守护进程，它有助于提供集群层面日志 集群层面的日志
概念
Container
容器，可以是 docker 启动的一个容器
Pod
- k8s 使用 Pod 来组织一组容器
- 一个 Pod 中的所有容器共享同一网络。
- Pod 是 k8s 中的最小部署单元
Volume
- 声明在 Pod 容器中可访问的文件目录
- 可以被挂载在 Pod 中一个或多个容器指定路径下
- 支持多种后端存储抽象(本地存储，分布式存储，云存储…)
Controllers
更高层次对象，部署和管理 Pod；
- ReplicaSet：确保预期的 Pod 副本数量
- Deplotment：无状态应用部署
- StatefulSet：有状态应用部署
- DaemonSet：确保所有 Node 都运行一个指定 Pod
- Job：一次性任务
- Cronjob：定时任务
Deployment
官方文档：Deployments
- 定义一组 Pod 的副本数目、版本等
- 通过控制器（Controller）维持 Pod 数目(自动回复失败的 Pod)
- 通过控制器以指定的策略控制版本（滚动升级，回滚等）
Service
官方文档：服务（Service）
- 定义一组 Pod 的访问策略
- Pod 的负载均衡，提供一个或者多个 Pod 的稳定访问地址
- 支持多种方式（ClusterIP、NodePort、LoadBalance）
Label
官方文档：标签和选择算符
标签，用于对象资源的查询，筛选
Namespace
官方文档：名字空间
命名空间，逻辑隔离
- 一个集群内部的逻辑隔离机制（鉴权，资源）
- 每个资源都属于一个 namespace
- 同一个 namespace 所有资源名不能重复
- 不同 namespace 可以资源名重复
API
官方文档：Kubernetes API
- 我们通过 kubernetes 的 API 来操作整个集群。
- 可以通过 kubectl、ui、curl 最终发送 http+json/yaml 方式的请求给 API Server，然后控制 k8s集群。k8s 里的所有的资源对象都可以采用 yaml 或 JSON 格式的文件定义或描述
快速体验
1、安装 minikube
https://github.com/kubernetes/minikube/releases
下载 minikube-windows-amd64.exe 改名为 minikube.exe
打开 VirtualBox，打开 cmd，
运行
minikube start --vm-driver=virtualbox --registry-mirror=https://registry.docker-cn.com
等待 20 分钟左右即可
2、体验 nginx 部署升级
提交一个ngnix deployment
kubectl apply -f https://k8s.io/examples/application/deployment.yaml升级ngnix deployment
kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml扩容 ngnix deployment
kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml
流程叙述
- 通过 Kubectl 提交一个创建 RC（Replication Controller）的请求，该请求通过 APIServer被写入 etcd 中
- 此时 Controller Manager 通过 API Server 的监听资源变化的接口监听到此 RC 事件
- 分析之后，发现当前集群中还没有它所对应的 Pod 实例，
- 于是根据 RC 里的 Pod 模板定义生成一个 Pod 对象，通过 APIServer 写入 etcd
- 此事件被 Scheduler 发现，它立即执行一个复杂的调度流程，为这个新 Pod 选定一个落户的 Node，然后通过 API Server 讲这一结果写入到 etcd 中，
- 目标 Node 上运行的 Kubelet 进程通过 APIServer 监测到这个“新生的”Pod，并按照它的定义，启动该 Pod 并任劳任怨地负责它的下半生，直到 Pod 的生命结束。
- 随后，我们通过 Kubectl 提交一个新的映射到该 Pod 的 Service 的创建请求
- ControllerManager 通过 Label 标签查询到关联的 Pod 实例，然后生成 Service 的Endpoints 信息，并通过 APIServer 写入到 etcd 中，
- 接下来，所有 Node 上运行的 Proxy 进程通过 APIServer 查询并监听 Service 对象与其对应的 Endpoints 信息，建立一个软件方式的负载均衡器来实现 Service 访问到后端Pod 的流量转发功能。
k8s 里的所有的资源对象都可以采用 yaml 或 JSON 格式的文件定义或描述
yaml文件详解
官方文档：Kubernetes 对象 | Kubernetes
参考：K8S之yaml 文件详解pod、deployment、service
概述
YAML语法格式：大小写敏感；
使用缩进表示层级关系；不支持Tab键制表符缩进，只使用空格缩进；
缩进的空格数目不重要，只要相同层级的元素左侧对齐即可，通常开头缩进两个空格；
字符后缩进一个空格，如冒号，逗号，短横杆（-) 等
"---" 表示YAML格式，一个文件的开始，用于分隔文件； 可以将创建多个资源写在同一个 yaml 文件中，用 --- 隔开，就不用写多个 yaml 文件了。
"#” 表示注释；
Deployment.yaml 文件解析
Deployment yaml文件包含四个部分：
- apiVersion：表示版本。版本查看命令：kubectl api-versions
- kind：表示资源
- metadata：表示元信息
- spec:：资源规范字段
Deployment yaml 详解：
apiVersion: apps/v1 # 指定api版本，此值必须在kubectl api-versions中。业务场景一般首选”apps/v1“
kind: Deployment # 指定创建资源的角色/类型
metadata: # 资源的元数据/属性
name: demo # 资源的名字，在同一个namespace中必须唯一
namespace: default # 部署在哪个namespace中。不指定时默认为default命名空间
labels: # 自定义资源的标签
app: demo
version: stable
annotations: # 自定义注释列表
name: string
spec: # 资源规范字段，定义deployment资源需要的参数属性，诸如是否在容器失败时重新启动容器的属性
replicas: 1 # 声明副本数目
revisionHistoryLimit: 3 # 保留历史版本
selector: # 标签选择器
matchLabels: # 匹配标签，需与上面的标签定义的app保持一致
app: demo
version: stable
strategy: # 策略
type: RollingUpdate # 滚动更新策略
rollingUpdate: # 滚动更新
maxSurge: 1 # 滚动升级时最大额外可以存在的副本数，可以为百分比，也可以为整数
maxUnavailable: 0 # 在更新过程中进入不可用状态的 Pod 的最大值，可以为百分比，也可以为整数
template: # 定义业务模板，如果有多个副本，所有副本的属性会按照模板的相关配置进行匹配
metadata: # 资源的元数据/属性
annotations: # 自定义注解列表
sidecar.istio.io/inject: "false" # 自定义注解名字
labels: # 自定义资源的标签
app: demo # 模板名称必填
version: stable
spec: # 资源规范字段
restartPolicy: Always # Pod的重启策略。[Always | OnFailure | Nerver]
# Always ：在任何情况下，只要容器不在运行状态，就自动重启容器。默认
# OnFailure ：只在容器异常时才自动容器容器。
# 对于包含多个容器的pod，只有它里面所有的容器都进入异常状态后，pod才会进入Failed状态
# Nerver ：从来不重启容器
nodeSelector: # 设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定
caas_cluster: work-node
containers: # Pod中容器列表
- name: demo # 容器的名字
image: demo:v1 # 容器使用的镜像地址
imagePullPolicy: IfNotPresent # 每次Pod启动拉取镜像策略
# IfNotPresent ：如果本地有就不检查，如果没有就拉取。默认
# Always : 每次都检查
# Never : 每次都不检查（不管本地是否有）
command: [string] # 容器的启动命令列表，如不指定，使用打包时使用的启动命令
args: [string] # 容器的启动命令参数列表
# 如果command和args均没有写，那么用Docker默认的配置
# 如果command写了，但args没有写，那么Docker默认的配置会被忽略而且仅仅执行.yaml文件的command（不带任何参数的）
# 如果command没写，但args写了，那么Docker默认配置的ENTRYPOINT的命令行会被执行，但是调用的参数是.yaml中的args
# 如果如果command和args都写了，那么Docker默认的配置被忽略，使用.yaml的配置
workingDir: string # 容器的工作目录
volumeMounts: # 挂载到容器内部的存储卷配置
- name: string # 引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
mountPath: string # 存储卷在容器内mount的绝对路径，应少于512字符
readOnly: boolean # 是否为只读模式
- name: string
configMap: # 类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
name: string
items:
- key: string
path: string
ports: # 需要暴露的端口库号列表
- name: http # 端口号名称
containerPort: 8080 # 容器开放对外的端口
# hostPort: 8080 # 容器所在主机需要监听的端口号，默认与Container相同
protocol: TCP # 端口协议，支持TCP和UDP，默认TCP
env: # 容器运行前需设置的环境变量列表
- name: string # 环境变量名称
value: string # 环境变量的值
resources: # 资源管理。资源限制和请求的设置
limits: # 资源限制的设置，最大使用
cpu: "1" # CPU，"1"(1核心) = 1000m。将用于docker run --cpu-shares参数
memory: 500Mi # 内存，1G = 1024Mi。将用于docker run --memory参数
requests: # 资源请求的设置。容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行
cpu: 100m
memory: 100Mi
livenessProbe: # pod内部的容器的健康检查的设置。当探测无响应几次后将自动重启该容器
# 检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可
httpGet: # 通过httpget检查健康，返回200-399之间，则认为容器正常
path: /healthCheck # URI地址。如果没有心跳检测接口就为/
port: 8089 # 端口
scheme: HTTP # 协议
# host: 127.0.0.1 # 主机地址
# 也可以用这两种方法进行pod内容器的健康检查
# exec: # 在容器内执行任意命令，并检查命令退出状态码，如果状态码为0，则探测成功，否则探测失败容器重启
# command:
# - cat
# - /tmp/health
# 也可以用这种方法
# tcpSocket: # 对Pod内容器健康检查方式设置为tcpSocket方式
# port: number
initialDelaySeconds: 30 # 容器启动完成后首次探测的时间，单位为秒
timeoutSeconds: 5 # 对容器健康检查等待响应的超时时间，单位秒，默认1秒
periodSeconds: 30 # 对容器监控检查的定期探测间隔时间设置，单位秒，默认10秒一次
successThreshold: 1 # 成功门槛
failureThreshold: 5 # 失败门槛，连接失败5次，pod杀掉，重启一个新的pod
readinessProbe: # Pod准备服务健康检查设置
httpGet:
path: /healthCheck # 如果没有心跳检测接口就为/
port: 8089
scheme: HTTP
initialDelaySeconds: 30
timeoutSeconds: 5
periodSeconds: 10
successThreshold: 1
failureThreshold: 5
lifecycle: # 生命周期管理
postStart: # 容器运行之前运行的任务
exec:
command:
- 'sh'
- 'yum upgrade -y'
preStop: # 容器关闭之前运行的任务
exec:
command: ['service httpd stop']
initContainers: # 初始化容器
- command:
- sh
- -c
- sleep 10; mkdir /wls/logs/nacos-0
env:
image: {{ .Values.busyboxImage }}
imagePullPolicy: IfNotPresent
name: init
volumeMounts:
- mountPath: /wls/logs/
name: logs
volumes:
- name: logs
hostPath:
path: {{ .Values.nfsPath }}/logs
volumes: # 在该pod上定义共享存储卷列表
- name: string # 共享存储卷名称 （volumes类型有很多种）
emptyDir: {} # 类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
- name: string
hostPath: # 类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
path: string # Pod所在宿主机的目录，将被用于同期中mount的目录
- name: string
secret: # 类型为secret的存储卷，挂载集群与定义的secre对象到容器内部
scretname: string
items:
- key: string
path: string
imagePullSecrets: # 镜像仓库拉取镜像时使用的密钥，以key：secretkey格式指定
- name: harbor-certification
hostNetwork: false # 是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
terminationGracePeriodSeconds: 30 # 优雅关闭时间，这个时间内优雅关闭未结束，k8s 强制 kill
dnsPolicy: ClusterFirst # 设置Pod的DNS的策略。默认ClusterFirst
# 支持的策略：[Default | ClusterFirst | ClusterFirstWithHostNet | None]
# Default : Pod继承所在宿主机的设置，也就是直接将宿主机的/etc/resolv.conf内容挂载到容器中
# ClusterFirst : 默认的配置，所有请求会优先在集群所在域查询，如果没有才会转发到上游DNS
# ClusterFirstWithHostNet : 和ClusterFirst一样，不过是Pod运行在hostNetwork:true的情况下强制指定的
# None : 1.9版本引入的一个新值，这个配置忽略所有配置，以Pod的dnsConfig字段为准
affinity: # 亲和性调试
nodeAffinity: # 节点亲和力
requiredDuringSchedulingIgnoredDuringExecution: # pod 必须部署到满足条件的节点上
nodeSelectorTerms: # 节点满足任何一个条件就可以
- matchExpressions: # 有多个选项时，则只有同时满足这些逻辑选项的节点才能运行 pod
- key: beta.kubernetes.io/arch
operator: In
values:
- amd64
tolerations: # 污点容忍度
- operator: "Equal" # 匹配类型。支持[Exists | Equal(默认值)]。Exists为容忍所有污点
key: "key1"
value: "value1"
effect: "NoSchedule" # 污点类型：[NoSchedule | PreferNoSchedule | NoExecute]
# NoSchedule ：不会被调度
# PreferNoSchedule：尽量不调度
# NoExecute：驱逐节点
Deployment.yaml 配置项说明
livenessProbe：存活指针
用于判断 Pod（中的应用容器）是否健康，可以理解为健康检查。使用 livenessProbe 来定期的去探测，如果探测成功，则 Pod 状态可以判定为 Running；如果探测失败，可kubectl会根据Pod的重启策略来重启容器。
如果未给Pod设置 livenessProbe，则默认探针永远返回 Success。
执行 kubectl get pods 命令，输出信息中 STATUS 一列可以看到Pod是否处于Running状态。
livenessProbe使用场景：有些后端应用在出现某些异常的时候会有假死的情况，这种情况容器依然是running状态，但是应用是无法访问的，所以需要加入存活探测livenessProbe来避免这种情况的发生。
readinessProbe：就绪指针
就绪的意思是已经准备好了，Pod 的就绪可以理解为这个 Pod 可以接受请求和访问。使用 readinessProbe 来定期的去探测，如果探测成功，则 Pod 的 Ready 状态判定为 True；如果探测失败，Pod 的 Ready 状态判定为 False。
与 livenessProbe 不同的是，kubelet 不会对 readinessProbe 的探测情况有重启操作。
当执行 kubectl get pods 命令，输出信息中 READY 一列可以看到 Pod 的 READY 状态是否为 True。
readinessProbe 使用场景：k8s 应用更新虽然是滚动升级方式，但是很多后端程序启动都比较久，容器起来了，但是服务未起来，而 k8s 只要容器起来了就会移除掉旧的容器，这种情况就会导致在更新发版的时候应用访问失败。这时候就需要配置 readinessProbe 就绪检测，保证新的 pod 已经能正常使用了才会移除掉旧的 pod。
initContainers：初始化容器
用于主容器启动时先启动可一个或多个初始化容器，如果有多个，那么这几个 Init Container 按照定义的顺序依次执行，只有所有的 Init Container 执行完后，主容器才会启动。由于一个 Pod 里的存储卷是共享的，所以 Init Container 里产生的数据可以被主容器使用到。
Init Container 可以在多种K8S资源里被使用到，如 Deployment、Daemon Set、Pet Set、Job 等，但归根结底都是在 Pod 启动时，在主容器启动前执行，做初始化工作。
tolerations：污点容忍度
节点污点：类似节点上的标签或注解信息，用来描述对应节点的元数据信息；污点定义的格式和标签、注解的定义方式很类似，都是用一个 key-value 数据来表示，不同于节点标签，污点的键值数据中包含对应污点的 effect，污点的 effect 是用于描述对应节点上的污点有什么作用；在 k8s 上污点有三种 effect（效用）策略，第一种策略是 NoSchedule，表示拒绝 pod 调度到对应节点上运行；第二种策略是 PreferSchedule，表示尽量不把 pod 调度到此节点上运行；第三种策略是 NoExecute，表示拒绝将 pod 调度到此节点上运行；该效用相比 NoSchedule 要严苛一点；从上面的描述来看，对应污点就是来描述拒绝pod运行在对应节点的节点属性。
pod 对节点污点的容忍度：pod 要想运行在对应有污点的节点上，对应 pod 就要容忍对应节点上的污点；pod 对节点污点的容忍度就是在对应 pod 中定义怎么去匹配节点污点；通常匹配节点污点的方式有两种，一种是等值（Equal）匹配，一种是存在性（Exists）匹配；等值匹配表示对应pod的污点容忍度，必须和节点上的污点属性相等，所谓污点属性是指污点的 key、value 以及 effect；即容忍度必须满足和对应污点的key、value 和 effect 相同，这样表示等值匹配关系，其操作符为 Equal；存在性匹配是指对应容忍度只需要匹配污点的 key 和 effect 即可，value 不纳入匹配标准，即容忍度只要满足和对应污点的 key 和 effect 相同就表示对应容忍度和节点污点是存在性匹配，其操作符为 Exists；
Service.yaml 文件解析
Service是Kubernetes的核心概念，通过创建Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并将请求负载分发到后端各个容器应用上。
apiVersion: v1 # 指定api版本，此值必须在kubectl api-versions中
kind: Service # 指定创建资源的角色/类型
metadata: # 资源的元数据/属性
name: demo # 资源的名字，在同一个namespace中必须唯一
namespace: default # 部署在哪个namespace中。不指定时默认为default命名空间
labels: # 设定资源的标签
- app: demo
annotations: # 自定义注解属性列表
- name: string
spec: # 资源规范字段
type: ClusterIP # service的类型，指定service的访问方式，默认ClusterIP。
# ClusterIP类型：虚拟的服务ip地址，用于k8s集群内部的pod访问，在Node上kube-porxy通过设置的iptables规则进行转发
# NodePort类型：使用宿主机端口，能够访问各个Node的外部客户端通过Node的IP和端口就能访问服务器
# LoadBalancer类型：使用外部负载均衡器完成到服务器的负载分发，需要在spec.status.loadBalancer字段指定外部负载均衡服务器的IP，并同时定义nodePort和clusterIP用于公有云环境。
clusterIP: string #虚拟服务IP地址，当type=ClusterIP时，如不指定，则系统会自动进行分配，也可以手动指定。当type=loadBalancer，需要指定
sessionAffinity: string #是否支持session，可选值为ClietIP，默认值为空。ClientIP表示将同一个客户端(根据客户端IP地址决定)的访问请求都转发到同一个后端Pod
ports:
- port: 8080 # 服务监听的端口号
targetPort: 8080 # 容器暴露的端口
nodePort: int # 当type=NodePort时，指定映射到物理机的端口号
protocol: TCP # 端口协议，支持TCP或UDP，默认TCP
name: http # 端口名称
selector: # 选择器。选择具有指定label标签的pod作为管理范围
app: demo
status: # 当type=LoadBalancer时，设置外部负载均衡的地址，用于公有云环境
loadBalancer: # 外部负载均衡器
ingress:
ip: string # 外部负载均衡器的IP地址
hostname: string # 外部负载均衡器的主机名
注意
port和nodePort都是service的端口，前者暴露给k8s集群内部服务访问，后者暴露给k8s集群外部流量访问。从上两个端口过来的数据都需要经过反向代理kube-proxy，流入后端pod的targetPort上，最后到达pod内的容器。NodePort类型的service可供外部集群访问是因为service监听了宿主机上的端口，即监听了（所有节点）nodePort，该端口的请求会发送给service，service再经由负载均衡转发给Endpoints的节点。
ingress.yaml 文件详解
apiVersion: extensions/v1beta1 # 创建该对象所使用的 Kubernetes API 的版本
kind: Ingress # 想要创建的对象的类别，这里为Ingress
metadata:
name: showdoc # 资源名字，同一个namespace中必须唯一
namespace: op # 定义资源所在命名空间
annotations: # 自定义注解
kubernetes.io/ingress.class: nginx # 声明使用的ingress控制器
spec:
rules:
- host: showdoc.example.cn # 服务的域名
http:
paths:
- path: / # 路由路径
backend: # 后端Service
serviceName: showdoc # 对应Service的名字
servicePort: 80 # 对应Service的端口