1、集群资源分类
名称空间级别：名称空间（Namespace）是用于隔离和组织资源的一种机制。每个资源都属于一个特定的名称空间，并且可以通过名称空间来对资源进行分组和管理。
. 工作负载型资源：pod 、各种控制器
. 服务发现及负载型资源：Service、Ingress
. 配置与存储型资源：Volume、CSI
. 特殊类型的存储卷：ConfigMap、Secret、DownwardAPI
集群级别：有一些资源是在整个集群范围内创建和管理的，而不是在特定的名称空间中。可以被多个名称空间中的资源共享和使用。通过集群级别资源，可以管理和配置整个集群的行为和属性。
. Node（节点）：Node 是 Kubernetes 集群中的工作节点，它可以运行容器化的应用程序。Node 代表集群中的物理或虚拟机器，并提供计算和存储资源。
.??Namespace（名称空间）：虽然名称空间通常是在特定的名称空间级别创建和管理的，但集群级别也有一个默认的名称空间（default），用于存放没有明确指定名称空间的资源。
.?Cluster（集群）：Cluster 是整个 Kubernetes 系统的顶层概念，它由一组相互连接的节点组成。Cluster 用于管理和协调集群中的各种资源。
.?StorageClass（存储类）：StorageClass 定义了用于创建 PersistentVolume 的存储配置。它描述了存储系统的属性和参数，并允许在集群级别定义不同的存储类。
.?ClusterRole（集群角色）和 ClusterRoleBinding（集群角色绑定）：ClusterRole 定义了一组权限，可以在整个集群范围内使用。ClusterRoleBinding 将 ClusterRole 授予用户、组或服务账户，以控制其对集群级别资源的访问权限。
.?CustomResourceDefinition（自定义资源定义）：CustomResourceDefinition 允许用户定义自己的自定义资源类型，这些资源类型可以在整个集群范围内使用。
元数据类型：根据指标进行对应操作。如：HPA、PodTemplate、LimitRange
2、YAML文件
https://www.jianshu.com/p/a2df63b7a901?v=1702538513542
3、pod生命周期
4、InitC
（1）说明
InitC容器与普通容器非常像，除了如下两点：
（1）Init容器总是运行到成功为止；即如果没有启动成功，k8s会不断重启该pod（除非pod对应的restarPolicy为Never，它不会重启）
（2）每个Init容器必须在下一个Inti容器启动之前完成
（2）? 测试如下
apiVersion: v1
kind: Pod
metadata:
? name: myapp-pod
? labels:
? ? app: myapp
spec:
? containers:
? ? ? - name: myapp-container
? ? ? image: busybox
? ? command: ['sh','-c','echo The app is running! && sleep 3600']
? initContainers:
? ? ? - name: init-myservice
? ? ? image: busybox
? ? command: ['sh','-c',' until nslookup myservice; do echo waiting for myservice; sleep 2;done;']
? ? -name: init-mydb
? ? image: busybox
? command: ['sh','-c','until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
kind: Service
apiVersion: v1
metadata:
? ? name: myservice
spec:
? ports:
? - protocol: TCP
? ? ? ? port: 80
? ? targetPort: 9376
---
kind: Service
apiVersion: v1
metadata:
? ? name: mydb
spec:
? ports:
? ? -protocol: TCP
? ? ? ? port: 80
? ? targetPort: 9377
kubectl?create -f??myservice.yaml? ?# 以yaml形式创建service
kubectl?create -f??mydb.yaml? ?# 以yaml形式创建service
kubectl?create -f??init-pod.yaml? ?# 以yaml形式创建Pod
kubectl? get pod -n kube-system #获取位于?kube-system?命名空间中的 Pod 列表
kubectl describe pod myapp-pod #查看myapp-pod信息（名称、运行状态、事件等）
kubectl log myapp-pod -c test? ?#查看myapp-pod中容器为test 的日志（只有一个容器，无需-c）
（3）特殊说明
1、在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出；
2、如果由于运行时或失败退出，将导致容器启动失败，它会根据Pod的restartPolicy指定的策略进行重试。然而，如果Pod的 restartPolicy 设置为 Always，Init 容器失败时会使用 RestartPolicy策略
3、在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在 Service中进行聚集。 正在初始化中的Pod处于Pending状态，但应该会将Initializing状态设置为 true
4、如果Pod重启，所有Init容器必须重新执行
5、对Init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器的 image字段，等价于重启该Pod;
6、Init容器具有应用容器的所有字段。除了readinessProbe，因为Init容器无法定义不同于完成(completion)的就绪(readiness)之外的其他状态。这会在验证过程中强制执行。readinessProbe?用于确定容器是否已准备好接收流量，而 Init 容器的主要目的是在应用容器启动之前执行一些初始化任务，因此没有必要进行 readiness 探针的检测。
7、在Pod中的每个app和Init容器的名称必须唯一;与任何其它容器共享同一个名称，会在验证时抛出错误
5、探针
init C 有一个很明显的缺点就是，如果init C 容器去探测某个容器（主容器依赖的容器）已经启动，等待init C容器结束之后，主容器再去访问该依赖容器，此时那个依赖容器挂了，就出现问题了，这个时候就需要探针来完成。探针可以通过主容器访问依赖容器，即在主容器内对依赖容器进行访问，比较合理。
探针是由kubelet对容器执行的定期诊断。要执行诊断，kubelet调用由容器实现的 Handler。
有三种类型的处理程序:
ExecAction: 在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
TCPSocketAction: 对指定端口上的容器的IP地址进行TCP检查。如果端口打开，则诊断被认为是成功的。
HTTPGetAction: 对指定的端口和路径上的容器的IP地址执行 HTTP Get 请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的
每次探测都将获得以下三种结果之一:
成功:容器通过了诊断。
失败:容器未通过诊断。
未知:诊断失败，因此不会采取任何行动
如下有两种探针
livenessProbe：存活检测，不存活，直接重启pod
readlinessProbe:就绪检测，不就绪，不将pod状态改为ready
（1）readinessProbe; (就绪探测)?
readinessProbe; (就绪探测) 指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与Pod 匹配的所有Service的端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为 Success。
如下：容器在启动时，1s后进行就绪检测，检测index1.html是否存在，不存在，3s后再检测，有的话，状态改为ready
apiVersion: v1
kind: Pod
metadata:
? name: readiness-httpget-pod
? namespace: default
spec:
? containers:
? ? - name: readiness-httpget-container
? ? image: wangyanglinux/myapp:v1
? ? imagePullPolicy: IfNotPresent
?readinessProbe:
?httpGet:
? ? ? ? ? port: 80
? ? ? ? ? path: /index1.html
? ? ? ? initialDelaySeconds: 1? ? ##容器启动后等待 1 秒后开始执行第一次探测。
? ? ? ? periodSeconds: 3? ? ??##每隔 3 秒执行一次探测。
创建完之后，比如 readiness-httpget-pod没同时出现read和running，则说明存在问题。
这里用到一个命令 ，进入pod的内的某个容器内查看明细
kubectlexecpod名 -c 容器 -it -- /bin/sh
（2）?livenessProbe：(存活探测)
livenessProbe：(存活探测) 指示容器是否正在运行。如果存活探测失败，则kubelet会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。
如下：这个存活探针，在容器启动后的第一秒开始，每隔 3 秒执行一次探测命令?test -e /tmp/live，如果?/tmp/live?文件存在，探测成功，容器被认为是存活的；如果文件不存在，探测失败，容器被认为出现了故障。
apiVersion: v1
kind: Pod
metadata:
? ? name: liveness-exec-pod
? ? namespace: default
spec:
? containers:
? - name: liveness-exec-container
? ? image: hub.atguigu.com/library/busybox
? ? imagePullPolicy: IfNotPresent
? ? command: ["/bin/sh","-c","touch /tmp/live; sleep 60; rm - rf /tmp/live; sleep 3600"]? ? ? ? ##容器启动时执行的命令，其中包括创建?/tmp/live?文件、等待 60 秒、删除?/tmp/live?文件、再等待 3600 秒。
?livenessProbe:
? ? ? exec:
? ? ? ? command: ["test","-e","/tmp/live"]? ? ?##探测命令，用于检测?/tmp/live?文件是否存在。
? ? ? initialDelaySeconds: 1? ? ##容器启动后等待 1 秒后开始执行第一次探测。
? ? ? periodSeconds: 3? ?##每隔 3 秒执行一次探测。
如下：这个存活探针，在容器启动后的第一秒开始，每隔 3 秒发送一个 HTTP GET 请求到容器的 "http" 端口的 "/index.html" 路径。如果探测请求返回成功的状态码（2xx 或 3xx），探测成功，容器被认为是存活的；如果返回失败的状态码（4xx 或 5xx）或超时，探测失败，容器被认为出现了故障。
apiVersion: v1
kind: Pod
metadata:
? name: liveness-httpget-pod
? namespace: default
spec:
? containers:
? ? - name: liveness-httpget-container
? ? image: wangyanglinux/myapp:v1
? ? imagePullPolicy: IfNotPresent
? ? ports:? #定义容器暴露的端口列表。
? ? ? - name: http
? ? ? ? containerPort: 80
?????livenessProbe:
?????????httpGet:
? ? ? ? ? ????port: http? ?##指定探测请求发送到容器暴露的名为 "http" 的端口。改为80亦可
? ? ? ? ????? path: /index1.html
? ? ? ????initialDelaySeconds: 1
? ? ? ????periodSeconds: 3
? ? ????? timeoutSeconds: 10? ? ##探测请求的超时时间为 10 秒。
apiVersion: v1
kind: Pod
metadata:
? name: probe-tcp
? namespace: default
spec:
? containers:
? - name : nginx
? ? image: myapp:v1
?livenessProbe:
? ? ? ? initialDelaySeconds: 5
? ? ? ? timeoutSeconds: 1
?tcpSocket:
? ? ? ? ? ? port : 80
? ? periodSeconds: 3
6、stop 、start
Pod hook(钩子) 是由Kubernetes 管理的kubelet 发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为pod 中的所有容器都配置 hook
Hook的类型包括两种：
exec : 执行一段命令
HTTP: 发送HTTP请求
apiVersion: v1
kind: Pod
metadata:
? name: lifecycle-demo
spec:
? containers:
? ? ? - name: lifecycle-demo-container
? ? ? image: nginx
? ? ? lifecycle:
?postStart:? ? ? ? ? ? ? ? ? ? ? ? ? #在容器启动后执行的钩子。
? ? ? ? ? ? exec:
? ? ? ? ? ? ? command: ["/bin/sh","-c","echo Hello from the postStart handler"]
?preStop:? ? ? ? ? ? ? ? ? ? ? ? ? ? #在容器终止之前执行的钩子。
? ? ? ? ? ? exec:
? ? ? ? ? ? ? command: ["/bin/sh","-c","echo Hello from the preStop handler"]
?Pod 中PodStatus的phase 可能存在的值
1、挂起(Pending): Pod已被Kubernetes系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度Pod的时间和通过网络下载镜像的时间，这可能需要花点时间
2、运行中(Running):该Pod已经绑定到了一个节点上，Pod中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态
3、成功(Succeeded):Pod中的所有容器都被成功终止，并且不会再重启
4、失败(Failed):Pod中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止