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状态退出或者被系统终止
