概述Prometheus 几乎已成为监控领域的事实标准，它自带高效的时序数据库存储tsdb，可以让单台 Prometheus能够高效的处理大量的数据，还有友好并且强大的 PromQL 语法，可以用来灵活的查询各种监控数据以及配置告警规则，同时它的 pull 模型指标采集方式被广泛采纳，非常多的应用都实现了 Prometheus 的 metrics 接口以暴露自身各项数据指标让 Prometheus

目录问题概述Forwarded问题分析X-Forwarded-Port解决方法参考文档问题概述近期开发因为一个请求的端口号问题找上了我，先贴代码这个应用的链路是流量到nginx后进行一次转发，转发到slb上，再负载到后端两台服务器。可以看到，代码中直接从请求获取到的server port，本来应该是获取到源客户端做请求使用的端口号，也就是当浏览器使用https协议并且路由到nginx时，nginx

在config-reloader容器中，我们指定了ConfigMap的watched-dir和volume-dir，并指定了webhook-url为localhost:5000/-/reload，当ConfigMap发生变化时，config-reloader会向该地址发送一个HTTP POST请求，触发应用程序的重新读取。其次，由于Controller需要监听ConfigMap的变化事件，并更新对

在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 资源的变