F_0125的博客

metadata:provisioner: kubernetes.io/no-provisioner # 这里用的是静态存储（没有动态供给）volumeBindingMode: WaitForFirstConsumer # 等到 Pod 真正调度到某个节点时才绑定卷用来描述一类存储的“模板”。。在本地环境学习时，表示不自动创建卷，需要手动准备 PV。意思是等到 Pod 确定在哪个节点上运行后，再真正去绑定存储，避免卷和节点调度冲突。

（1）Pod 重启策略（RestartPolicy）应用于 Pod 内的所有容器，并且仅在 Pod 所处的 Node 上由 kubelet 进行判断和重启操作。（4）Scheduler 同样通过 apiserver 的 watch 接口更新到 Pod 可以被调度，通过算法给 Pod 分配节点，并将 pod 和对应节点绑定的信息交给 apiserver，apiserver 写到 etcd，然后将 Pod 交给 kubelet。① Always：当容器失效时，由 kubelet 自动重启该容器；

① requiredDuringSchedulinglgnoredDuringExecution：硬规则，必须满足指定的规则，调度器才可以调度 Pod 至 Node 上（类似 nodeSelector，语法不同）；定向调度，当需要手动指定将 Pod 调度到特定 Node 上，可以通过 Node 的标签（Label）和 Pod 的 nodeSelector 属性相匹配。（2）TCPSocketAction：通过容器的IP地址和端口号执行 TCP 检查，若能建立 TCP 连接，则表明容器健康。

服务选择器（Selector）存在时：当HeadlessService定义了selector时，Kubernetes控制平面会根据selector筛选出匹配的Pod，并为这些Pod创建对应的DNSA记录。在这个示例中，创建了一个名为myheadlessservice的HeadlessService，它会筛选出带有app:myapp标签的Pod，并将客户端对端口80的请求转发到这些Pod的8080端口。普通Service会有一个虚拟的集群IP，客户端通过访问这个集群IP来间接访问后端的Pod。

kube-proxy是Kubernetes集群中一个关键的组件，主要负责实现Kubernetes服务（Service）的网络代理和负载均衡功能。kube-proxy是一个运行在每个Kubernetes节点上的守护进程。它监听KubernetesAPI服务器中关于服务（Service）和端点（Endpoints）的变化，并根据这些信息来配置节点上的网络规则，确保集群内的网络流量能够正确地路由到相应的Pod上。

DaemonSet 会在每个节点上创建一个 Pod，Pod 的标签为 name: testpod。DaemonSet 会在每个节点上部署一个 Pod 副本。如果新节点加入集群，DaemonSet 会自动在新节点上创建 Pod；列出集群中所有的 DaemonSet，确认 test-demonset是否创建成功。- DaemonSet 则确保每个节点上都运行一个 Pod，适合。在每个节点上运行日志收集器（如 Fluentd、Filebeat）。在每个节点上运行存储守护进程（如 GlusterFS、Ceph）。

将名为 `nginx-deployment` 的 Deployment 中名为 `nginx` 的容器镜像更新到 `nginx:1.161` 版本。这条命令会将 `nginx-deployment` 回滚到 Revision 2 的状态。它会创建一个新的 ReplicaSet，并使用新镜像启动 Pod，同时逐步终止旧 Pod，以确保服务不中断。通过以上命令和流程，可以轻松管理 Kubernetes 中应用的版本更新与回滚，确保服务的稳定性和可靠性。这条命令会显示更新的实时进度，直到更新完成或超时。