在Kubernetes集群中，CoreDNS通常作为默认的DNS插件运行在kube-system命名空间中，它通过监听ClusterIP类型的Service的DNS请求，并将其解析为对应的Pod IP地址。Service域名解析：当一个Pod或其他服务访问Kubernetes集群中的另一个Service时，它会使用目标Service的名称作为域名进行解析。插件会根据请求中的域名查找对应的Servi

至此，整一个websocket的前后端调用就完成了。可见的是，这种是比较初级的做法，未来将会看见更优雅的实现。

request 中使用了环境变量配置文件 .env.development 中的 BASE_URL ，而该文件中默认值并不是个远程 URL ，而是 /dev-api，也就是说现在业务 API 会请求到我们的 GO API 中，而用户 API还是会走本地的数据模拟；上一章中只是为了快速测试，独立出了一个自定义的 request 文件，在上实际生产环境中，肯定是需要构建我们的用户系统，并且这部分功能由

etcd备份/恢复对于恢复etcd集群，官方建议重启k8s组件，具体说明如下：说明：如果集群中正在运行任何 API 服务器，则不应尝试还原 etcd 的实例。相反，请按照以下步骤还原 etcd：停止所有API 服务实例在所有 etcd 实例中恢复状态重启所有 API 服务实例我们还建议重启所有组件（例如kube-scheduler、kube-controller-manager、kubelet），

由于 K8S 内置了许多的 Controller 来对各种各样的资源进行 List & Watch，因此也会产生各种不同的事件（Event），其中部分事件是需要我们作为告警来处理的，比如 ReadinessProbe Failed 这种事件，我们需要在其到达失败阈值之前获得通知并做及时处理。其中，因为钉/企微的 Webhook 机器人有固定的消息模版用于展示，我们需要在预先定义好的模版中填充关于事

在进行运维 paas 平台开发时，我们会经常接触到需要调 Kuberenetes api 的情况。因为云厂商只封装了部分的 Kuberenetes api 提供接口访问，部分 API 如获取 event ，云厂商还是建议使用原生的 Kuberenetes api 去做请求，这就要求我们对 k8s api 有相当的熟悉度，这可能需要详细阅读官方的 API 文档。本文提供一种方式，通过探查 kubec

这里只是做一个思路的展示，因为诸如或者容器日志或者远程 shell 这类复杂的操作，往往通过多个资源的组合(namespace、deployment、pod..)来获取最终操作的对象，我们不可能去多次请求api，一是延迟问题，二是 apiserver 的压力问题（这个影响比较小）。有了本地缓存 map，我们就可以通过加入 deployment 对应类型的 informer 去 watch 资源的变

该路由通过项目路径 '@/views/workloads/deploylist' 指向了一个组件，因此我们需要在 /src/views/workload 下新建文件 deploylist.vue；3.根据我们后端 api 的返回结果，需要将请求拿到的结果做一定处理，并将处理后的结果赋给 data 中的表单对象，并在 html 中选择返回结果中合适的成员变量插入对应的表列中。仿照内置的 templa

目录背景出现问题问题追溯解决方法参考文档（issue 和 pull request 已按照时间线梳理）本篇建议建立在以下文档之上进行阅读： 配置存活、就绪和启动探测器关于 K8S 探针的最佳实践 众所周知，日志作为实现软件可观测性的三大支柱之一，为了解系统运行状况，排查系统故障提供了关键的线索，在运维管理中起着至关重要的作用。Kubernetes 提供了两种原生的日志形式——审计（Audit）和事

lite应该是不将docker image的镜像打进sealer镜像中，我们的目的是制作离线安装包，指定container是创建6个容器来作为k8s的3个master节点和3个node节点，我在执行过程中得到了找不到clusterfile的返回结果，clusterfile是sealer中对k8s集群的配置文件。3.还有就是目标要求离线安装，那么无论是operator还是helm的安装方式都需要导入