此前，在的存储卷类型介绍中，emptyDir只在节点本地使用。创建一个pod，一个存储卷，pod被删除，存储卷也会被删除.empryDir数据随着pod的创建而创建，随着删除而删除empryDir可以当临时目录，或者缓存使用(关联宿主机的目录可以是宿主机的内存，将内存放到pod存储卷)。没有持久化。本次将详细实验一下emptyDir的用法 emptyDir存储卷 1，pod上定义volume,vo

此前在存储卷类型中提到，hostPath位于主机路径，在宿主机创建目录挂载。一定意义的持久性。pod所在宿主机之上的，脱离pod容器名称空间之外的，宿主机的文件系统某一个目录与pod建立关系。当pod被删除，存储卷不会被删除。只要同一个pod调度到同一个节点，数据依然可被正常使用。 volumes： hostPath: path: type type字段支持为了测试效果，在三台node上都创建这个

在之前ConfigMap介绍中，我们知道ConfigMap存在的目的并不是为pod提供存储空间来用的，而是给用户提供从集群外部向pod内部应用注入配置信息，本篇笔记简单介绍如何注入一些配置信息，发分别是环境变量和文件的方式。在configMap中，会用到configMapKeyRef和secretKeyRef.configMap也属于名称空间资源。在创建时，没有spec，而有data，结构相对简单

在kubernets上有一些服务和客户端需要与api server交涉，并且集群内部会运行类似的pod资源，这些资源是需要访问api server的 ，如: CoreDNS,以及dashboard dashboard提供一个web界面来管理kubernetes，通过service暴漏到外部，通过浏览器打开使用。当然会有通过dashboard来进行增删改查资源，那意味着dashboard这个pod就

在kubernets中运行pod资源的节点中，master节点运行控制组件，主要控制组件如： apiserver controller-manager scheduler 除此之外，master还依赖ETCD存储节点，或者是一个有冗余能力的存储集群。在使用kubeadm部署时候，这些组件会被运行成pod应用程序，并且是静态pod。简单的讲，就是运行在master本地的一个守护进程。从这个方面讲，m

Pod自身的亲和性调度分为两种表示形式，第一种podinity(亲和性)，第二张podAffinity(反亲和性) pod亲和性 pod与pod更倾向运行在一起。一般出于高效通讯的需求把pod对象组织在相近的位置，同一个节点，同一个机架，同一个机房，甚至于同一个区域或者地区，便于pod通讯。但是有些时候在部署两套系统的时候，出于一些安全或者其他的考虑，不能够部署在一起的时候，就需要反亲和性。 po

在前面的两种方式中，都是由pod去选择的，节点被动选择运行。而污点调度方式就给了节点的选择权。让节点可以选择让那些pod运行在节点上。总的来说，污点就是定义在节点上的键值属性数据。 此前，我们知道，键值属性有三类，第一类叫标签，第二类叫注解，第三类便是污点。污点用在节点之上，而前两类所有资源对象都可以使用。 pod亲和性和node亲和性都是pod的属性，而污点是节点的属性 污点也是一种键值属性，主

hpa hpa有着非常强大的功能，支持应用规模的自动伸缩。如果某一个pod，资源利用率达到一个临界值后，会自动的修改Deployment的replicas值，这种方式也有自动计算结果得到的。比如说，我有5个pod，我期望每个负载率是90% 就进行扩展一个pod，依次类推。当负载降下来的时候就在自动所容到正常的个数。 hpa是有两个版本，v1使用核心指标定义，而核心指标中只有cpu和内存，而内存不可

Kubernetes需要确保在 Pod 中运行的 应用是健康的。一旦应用出现问题，kubelet作为守护进程会根据为 Pod 设置的重启策略(restartPolicy)重启 Pod。现在的问题是 k8s 如何检测不健康的应用程序？答案是通过Probes。 restartPolicy默认为：Always Liveness、Readiness 和 Startup 探针 Kubernetes有 3 种

应用程序并不总是在稳定状态下运行。会根据日期、时间或特定事件而波动。CPU 需求各不相同，运行时内存和网络需求也各不相同。而应用程序不断变化的需求，由Kubernetes来调度程序分配计算或内存资源，这些可能会导致Kubernetes上的node或者pod处于不可用状态的原因之一，而这些pod最终是关联到应用程序上，只有将这些资源被分配给其他应用程序或暂停，直到一切结束。 这种重新分配可能有意或意

通常，无状态的应用多数情况下以deployment控制器下运行，在deployment更新中，当配置清单发生变化后，应用这些新的配置。 我们假设一些都ok，也成功拉取镜像，并且以默认的25%进行滚动更新，直到更新完成。 kubectl apply -f test1.yaml 然而这一切按照预期进行，没有任何问题。 kubectl只是将配置推送到k8s后，只要配置清单没有语法或者冲突问题，返回的是0

如下图所示 我们先查看下pod的调度情况，分别是10.11.1.45和10.11.0.10在不同的两个节点，并且是不同的网段 不同的网段，那么久需要查找路由表，看路由信息 [root@master1 ~]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE marksugar-deployment-578cdd567b-9

流量治理 在istio1.5后的版本，istiod充当控制平面，并且将配置分发到所有的sidecar代理和网关，能够支持网格的应用实现只能话的负载均衡机制。 而envoy通过简单的二次开发后在istio中称为istio-proxy，被用于围绕某个pod，以sidecar的模式允许在某个应用的pod中。除此之外envoy还负责ingress和egress，分别是入向和出向网关。 在k8s中，一旦is

紧接前面，这篇我们希望访问dpment服务的请求在百分之90的流量在原来的v10的pod，而百分之10的在新的v11的pod，因此我们配置weight来实现基于权重比例的流量切割 首先部署dpment-a和dpment-b 仍然需要配置service关联到后端的pod标签 apiVersion: v1 kind: Service metadata: name: dpment namespace:

在 Kubernetes 中，同一命名空间中的任何 Pod 都可以使用其 IP 地址相互通信，无论它属于哪个部署或服务。虽然这种默认行为适用于小规模应用，但在规模扩大和复杂度增加的情况下，Pod 之间的无限通信可能会增加攻击面并导致安全漏洞。 在集群中实施 Kubernetes 网络策略可以改善以下方面： 安全性： 使用 Kubernetes 网络策略，你可以指定允许哪些 Pod 或服务相互通信，

作者： Xing Yang (VMware) 最初在 1.19 中引入的 CSI 卷健康监控功能在 1.21 版本中进行了大规模更新。 为什么要向 Kubernetes 添加卷健康监控？ 如果没有卷健康监控，在 PVC 被 Pod 配置和使用后，Kubernetes 将不知道存储系统的底层卷的状态。 在 Kubernetes 中配置卷后，底层存储系统可能会发生很多事情。 例如，卷可能在 Kuber

作者： Mayank Kumar (Salesforce) 译者： Xiaoyang Zhang（Huawei） Kubernetes StatefulSet， 自 1.5 版本中引入并在 1.9 版本中变得稳定以来，已被广泛用于运行有状态应用。它提供固定的 Pod 身份标识、 每个 Pod 的持久存储以及 Pod 的有序部署、扩缩容和滚动更新功能。你可以将 StatefulSet 视为运行复杂有

作者： Mahé Tardy (Quarkslab) 从 Kubernetes v1.25 开始，PodSecurityPolicy (PSP) 准入控制器已被移除。 在为 Kubernetes v1.21 发布的博文 PodSecurityPolicy 弃用：过去、现在和未来 中，已经宣布并详细说明了它的弃用情况。 本文旨在提供 PSP 诞生和演变的历史背景，解释为什么从未使该功能达到稳定状态，

作者： Jonathan Dobson (Red Hat) CSI 内联存储卷是在 Kubernetes 1.15 中作为 Alpha 功能推出的，并从 1.16 开始成为 Beta 版本。 我们很高兴地宣布，这项功能在 Kubernetes 1.25 版本中正式发布（GA）。 CSI 内联存储卷与其他类型的临时卷相似，如 configMap、downwardAPI 和 secret。 重要的区别

作者： Deep Debroy (Apple) Kubernetes 1.25 引入了对 kubelet 所管理的新的 Pod 状况 PodHasNetwork 的 Alpha 支持， 该状况位于 Pod 的 status 字段中 。对于工作节点，kubelet 将使用 PodHasNetwork 状况从容器运行时 （通常与 CNI 插件协作）创建 Pod 沙箱和网络配置的角度准确地了解 Pod