17.K8s实践17-3种探针保障应用在容器内高可用 场景与需求： POD中的容器在启动后才能接管业务流量，如果启动失败要能够重启； 如果容器在运行过程中，出现OOM错误或网络不通等，要能够使得该容器不再提供服务，且尝试自愈（重启）。 针对上面的需求，Kubernetes提供三种探针来解决。 startupProbe探针: 探测容器是否已经启动。用在有些POD启动需要很长时间的场景，避免每隔一段时间使用其他探针探测一次。 如果提供了启动探针，则所有其他探针都会被禁用，直到此探针成功为止，即容器启动时优先使用startupProbe探测容器是否已经启动。 如果启动探测失败，kubelet 将kill POD中的容器，而容器依其重启策略（RestartPolicy）进行重启。 如果探测容器启动成功，将会启动容器中的其他两个探针（如果启动了的话），即readinessProbe和livenessProbe会接管进行下一步的探测。 如若没有提供startupProbe探针，默认容器启动成功。 readinessProbe探针：探测容器是否准备好对外提供服务。 容器启动后，如果探测 ...

场景：应用基于Kubernetes部署，应用开发者受限登陆集群节点下载文件。当Java（或者其他）应用出现OOM异常需要生成heap dump二进制文件。 Kubernetes部署负载时，如果不指定POD的重启策略（RestartPolicy），则默认为Always策略。也即意味着，如果这个容器主进程出现故障，Kubelet会自动将这个容器重启。 遗憾的是，容器故障时，由于Kubelet会很快自动重启容器，所以我们没法人工进入做java的heap dump这个动作。那是不是就没法获取到应用的heap dump信息呢？当然不是，需要注意的是，容器重启但是POD并没有重启，也就是说POD被调度的节点没有变化，也就意味着，我们可以将容器生成的文件直接存放到节点中，集群管理员可以协助去下载heap dump文件。 1. 集群管理员获取heap dump文件按照上面的思路，对于有整个集群权限的管理员而且，可以获取到节点中的任何数据，在容器退出前导出heap dump即可： Deployment.yaml 123456789101112131415161718192021222324apiVe ...

需求背景：一些自研插件通过sidecar容器提供服务，容器需要获取到当前所在节点的IP与hostname作为环境变量传递给应用。 Kubernetes通过环境变量可满足该需求。通过环境变量获取的内容如下： status.podIP - POD的IP spec.serviceAccountName - Pod 服务帐号名称, 版本要求 v1.4.0-alpha.3 spec.nodeName - 节点名称, 版本要求 v1.4.0-alpha.3 status.hostIP - 节点 IP, 版本要求 v1.7.0-alpha.1 此外，Kubernetes通过downward API卷可以给容器提供POD信息、以及容器限额信息，详细可参考官网- Downward API 的能力 实践 - 向容器中注入主机IP与主机Hostnamedeploy.yaml 12345678910111213141516171819202122232425262728293031kind: DeploymentapiVersion: apps/v1metadata: name: nginx-dep ...

通常容器的生命周期是不固定的、甚至是比较短的，但是它生成的数据可能是有价值的需要长期保存的，即持久化存储。在Kubernetes中持久化存储主要通过PV与PVC来实现。 PV：PersistentVolume（持久化卷）。 PVC：PersistentVolumeClaim（持久化卷声明）。 PVC与PV的关系类似于POD与节点的关系，PVC消耗的是PV资源，POD消耗的是节点资源。一般来讲，是资源管理员或者SRE运维团队提前创建好PV存储资源，然后开发团队通过PVC来声明使用PV资源（是有点麻烦了）。 除了上面的两个基本资源对象以外，Kubernetes还引入了一个StorageClass对象，这样就可以对存储进行分类，比如是快存储还是慢存储，是块存储、文件存储还是对象存储，是AWS的还是其他厂家的存储；同时通过StorageClass对象，Kubernetes就可以自动创建PV了，不需要管理员提前创建好PV再给开发成员通过PVC声明使用。 也即是说持久化存储最终是通过PV来实现的，但是细化到具体存储资源，其实是多样化的，可以是Kubernetes主机本身的节点上挂载的磁盘，也可 ...

1. 背景大规模集群，每个节点上有大量镜像需要定期维护，如果通过Kubelet GC机制垃圾回收镜像的话，可能会导致原本还在用的镜像被误删除。所以需要能指定镜像删除，同时不必登陆到每个节点上手动删除镜像。 2. 原理核心思路是，在节点中的POD中获取特权，通过Docker on Docker方案，链接到主机docker socket上：/var/run/docker.sock，然后可通过Docker客户端操作主机，如：docker rmi命令强制删除主机镜像。如果使用docker rmi则要求POD使用的镜像中安装有docker，稍微麻烦。 其实docker客户端多种多样，其本质都是操作HTTP Restful API，还可以使用python、go等docker客户端，不过最简单是使用curl命令行调用HTTP Restful API了。 1curl --unix-socket /var/run/docker.sock -X DELETE http://localhost/[docker Version]/images/[imageID] 详细描述参考：https://docs.do ...

相对于HPA横向弹性伸缩增、减POD，VPA垂直弹性会在现有POD基础上对POD的CPU与内存进行弹性，它根据容器资源使用率自动设置 CPU 和 内存 的requests，从而允许在节点上进行适当的调度，以便为每个 Pod 提供适当的资源。VPA既可以缩小过度请求资源的容器，也可以根据其使用情况随时提升资源不足的容量。 说明：VPA与HPA不能同时工作，二者只能选其一，且VPA目前还未大规模推广商用，仅供测试。 依赖条件： metrics-server：跟HPA一样，需要有metrics-server识别CPU、内存指标数据。 vertical-pod-autoscaler：是Kubernetes的CRD对象，可在https://github.com/kubernetes/autoscaler.git获取安装包到集群中安装使用。 metrics-server与vertical-pod-autoscaler也是通过POD的方式运行在kube-system命名空间下，查看如下结果则表示安装成功。 12345$ kubectl get po -nkube-system |grep ...

一般ConfigMap用于保存通用配置信息，属于明文信息，不能保存密钥，如果要保存密钥等加密信息，Kubernetes提供的解决方案是使用Secret对象，通过Secret进行加密并传递给容器作为变量使用，应用根据加解密算法进行解密使用。 Secret 主要使用的有以下三种类型： Opaque：base64 编码格式的 Secret，用来存储密码、密钥等；但数据也可以通过base64 –decode解码得到原始数据，所以加密性很弱。 kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息。 kubernetes.io/service-account-token：用于被 ServiceAccount ServiceAccount 创建时 Kubernetes 会默认创建一个对应的 Secret 对象。Pod 如果使用了 ServiceAccount，对应的 Secret 会自动挂载到 Pod 目录 /run/secrets/kubernetes.io/serviceaccount 中。 如下在集群中查询secret信息： 1 ...

应用的配置在Kubernetes中可通过ConfigMap资源对象来实现，避免被直接写死到应用程序中，比如应用连接一个redis服务，下一次想更换另一个，如果写死的话，就得重新修改代码，重新制作新镜像。而利用ConfigMap就可以很方便地向容器中注入配置信息。类似于Windows/Linux中的环境变量的配置。 不过需要注意的是，ConfigMap一般是保存非安全的配置信息，比如服务连接地址，环境变量参数，服务端口等等，如果是涉及到密钥等敏感信息，则不适合用ConfigMap，因为ConfigMap是明文保存的，如果保存密钥等信息就会引起安全问题了。 1. 实践1：通过ConfigMap向容器中注入数据库端口值最直观的方式是在命令行中直接注入参数值，通过--from-literal参数传递配置信息。 123456789101112131415161718192021222324252627$ kubectl create configmap cm-demo1 --from-literal=db.host=localhost --from-literal=db.port=3306 ...

除了基于 CPU 和内存来进行自动扩缩容之外，有些业务需要基于自定义指标进行HPA弹性伸缩，通用做法是结合prometheus能力。 如上图示，基于自定义指标进行HPA弹性的核心原理为： 业务能够暴露指标，注意是prometheus格式的指标，即能被prometheus识别，一般是暴露到prometheus的/metrics下。 Kubernetes并不能识别Prometheus格式指标，所以这时需要通过Prometheus Adapter将其进行转换，转换为Kubernetes metrics API. Kubernetes的HPA控制器通过Kubernetes metrics API识别到业务指标变化，根据HPA策略来发起POD的弹性伸缩。 1. 准备工作 集群完成安装prometheus插件 prometheus插件已经安装完成prometheus-adapter 业务定义暴露的指标 2. 验证步骤1）基于自定义指标进行HPA弹性伸缩，首先需要业务侧暴露自己的指标； 2）在prometheus中查阅到业务自定义指标，基于指标定义HPA策略 3）模拟增加业务流量触发H ...

HPA弹性1：基于CPU与内存指标实现弹性伸缩Kubernetes中弹性伸缩最主要的就是使用HPA（Horizontal Pod Autoscaling）和CA（Cluster AutoScaling）两种弹性伸缩策略，HPA负责工作负载弹性伸缩，也就是应用层面的弹性伸缩，CA负责节点弹性伸缩，也就是资源层面的弹性伸缩。 通常情况下，两者需要配合使用，因为HPA需要集群有足够的资源才能扩容成功，当集群资源不够时需要CA扩容节点，使得集群有足够资源；而当HPA缩容后集群会有大量空余资源，这时需要CA缩容节点释放资源，才不至于造成浪费。 本文先演示HPA弹性伸缩，基于CPU和内存使用率实现POD实例的弹性。 1. 准备工作本次实验基于EKS集群，需要集群安装metrics-server插件，该插件能够收集包括Pod、Node、容器、Service等主要Kubernetes核心资源的度量数据,并通过标准的 Kubernetes API 把数据暴露出来。 2. 工作原理 在负载中指定多个POD副本，metrics-server可收集到这些POD使用的CPU与内存度量数据； 创建一个Hori ...