首先下载相应的go pkg接下来需要创建控制器和ManagerOperator的本质是一个可重入的队列编程模式，而Manager可以用来管理Controller、Admission Webhook，包括访问资源对象的client、cache、scheme、提供了一个简单的依赖注入机制、优雅关闭的信号处理机制等。 参见官方文档中的示例代码opsController.go先监听官方资源，比如Ingre

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

于是通过grpc调用的方式，并规定了grpc的接口方法和字段，各个厂商必须实现，也就是我们所谓的CRI（ContainerRuntimeInterface）。RunC是容器运行工具，纯从系统角度，Runc才是底层运行时，Runc是Docker中最为核心的部分，容器的创建、运行、销毁等等操作最终都将通过调用Runc完成。Containerd是容器运行时，从容器编排角度，Containerd是容器运行

目录问题概述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的变化事件，并更新对

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

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

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

应用背景项目通常有多个 k8s 集群环境，dev、testing、staging、prod，kubetcl 在多个环境中切换，操作集群 Pod 等资源对象，前提条件是将这三个环境的配置信息都写到本地机或是K8S外部一台管理机器的 $HOME/.kube/config 文件中。本文将介绍如何通过将多个kubeconfig文件合并为一个来配置多集群的访问，从而进行K8S多集群统一管理。默认情况下 ku

可以看到Pod内部的resolv.conf 内容，其中nameserver指定DNS解析服务器IP为 “10.96.0.2” ，这个IP地址正是Kubernetes集群CoreDNS的Service “kube-dns” 的 cluterIP，说明当Pod内部进行域名解析时，确实是将查询请求发送到Service “kube-dns” 提供的虚拟IP进行域名解析 既然Pod 中 DNS配置文件没问题