菜鸟运维升级之路

在云原生架构中，服务发现是微服务治理的关键环节。本文将详细介绍如何通过kube-consul-register实现Kubernetes服务到Consul的自动注册，解决传统手动注册的痛点。多模式注册（Single/Node/Pod模式）注解驱动的灵活配置自动健康检查集成服务状态实时同步这是一个将Kubernetes中的Pod/Service/Endpoint自动注册到Consul服务的工具，实现服务自动发现功能。

在云原生技术蓬勃发展的今天，Kubernetes（K8S）已成为容器编排领域的事实标准，而监控作为保障系统稳定性和可观测性的核心环节，其重要性不言而喻。Prometheus 凭借其强大的时序数据采集能力和灵活的查询语言（PromQL），成为云原生监控体系的基石。然而，在动态变化的 K8S 环境中，传统静态配置的服务发现方式往往难以适应频繁的服务扩缩容和实例迁移。如何实现监控目标的自动化发现与动态管理，成为提升运维效率的关键挑战。为此，服务发现技术应运而生。

在云原生架构中，服务注册与发现是微服务架构的核心组件之一。随着Kubernetes成为容器编排的事实标准，如何将传统服务注册中心与Kubernetes原生服务发现机制相结合，成为企业级应用面临的重要课题。本文详细介绍如何利用HashiCorp Consul实现Kubernetes服务的自动注册与发现，通过开发定制化工具解决实际生产环境中的服务治理难题,并结合Prometheus实现监控。

在传统的单机环境下，容器之间的网络通信相对简单，通常通过Docker默认的网桥模式就可以实现。然而，将容器部署到分布式的集群环境中时，跨主机的容器网络通信就成为了一个亟待解决的问题。因为在Docker的默认配置下，不同宿主机上的容器是无法直接通过IP地址进行互相访问的。这是因为每个宿主机上的Docker网络都是独立的，它们各自管理着自己的私有网段。这种隔离虽然在安全性方面有所裨益，但也阻碍了容器之间的直接通信。因此为了解决这个"跨主通信"的难题，容器社区提出了多种网络方案。

因我们的前后端项目都部署在k8s集群中,前端项目采用npm和node管理事故背景: 某天前端同事在测试环境更新完一个前端服务后,访问正常,然后按照正常流程上线到生产环境,但是，在生产环境更新完成后,测试同事反馈访问报502错误,我就去服务器排查刚才发布的服务,检查pod状态是RUNNING状态,更新时间也是几分钟前,从表面看没有问题，由此,赶紧回滚镜像,停止上线,拉开问题排查与解决之路~

本篇文章主要是我在学习k8s时自己整理的学习笔记，内容主要偏入门和基础,可以在学习k8s时用做参考。同时这篇文章主要包含k8s的基础概念、各控制器的策略使用方法、卷存储、网络插件的一些使用方法和排查方法。都是自己在自学时的整理笔记，。对新手友好，如果你有使用过k8s,那么大可不必看这篇文章。这篇文章也会随时更新，当有遇到新的内容或者技术时都会更新到此。这片文章的学习笔记依赖于k8s1.18版本。够用!!

QoS指的是Quality of Service,中译就是服务质量,也就是k8s用来标记各个pod对于资源使用情况的质量,QoS会直接影响当节点资源耗尽的时候k8s对pod进行evict的决策。官方的描述在这里.：k8s会以pod的描述文件里的资源限制，对pod进行分级.此处的资源限制指的就是k8s资源控制器yaml文件中的Request和Limit.如下表格所示。QoS条件Guaranteed(可靠)

将平常维护集群时使用的命令做一个整理提示：以下是本篇文章正文内容，下面案例可供参考后续有新命令在随时更新。

CoreDNS 是 Kubernetes 集群中的 DNS 服务，它提供了非常强大的 DNS 配置功能 , 支持对 DNS 请求进行各种操作，例如转发、重写、负载均衡等。在 CoreDNS 的众多插件中，rewrite 插件可以用于修改 DNS 请求中的域名，使其转发到不同的目标。rewrite 插件通过修改域名的方式，实现对请求的路由改变。

在一个k8s集群中,微服务以 Pod形式 运行在我们的集群中，这些 Pod 的副本通过Service 服务暴露，当一个外部请求到达 Service 的虚拟 IP 时，如何将请求转发到其中一个底层 Pod？这便是本篇文章的核心思想。kube-proxy是k8s网络代理核心组件,部署在每个Node节点上,主要维护节点上的网络规则。它是实现service的通信与负载均衡机制的重要组件。

在Kubernetes中，挂载存储卷是容器化应用的常见需求。然而当我们将整个卷挂载到容器中的某个目录时，可能会覆盖目标目录中已有的文件，尤其是在共享目录或有多个应用访问同一卷的场景下。为了避免这种情况，subPath字段应运而生，它允许精确指定要挂载的子目录或文件，从而避免覆盖目录中其他重要数据。在这篇文章中，我们将深入探讨subPath字段的使用方法，展示如何通过这一功能实现精准挂载，确保不干扰或覆盖目录中的其他文件。

在 Kubernetes 集群中，CoreDNS 是一个关键的基础组件，负责域名解析和服务发现。无论是内部服务通信还是访问外部域名，CoreDNS 都为我们提供了高效、灵活的支持。本文将通俗易懂地介绍 CoreDNS 的作用、工作流程，并通过一些常见的配置案例帮助你更好地理解它的功能DNS架构二、coredns基础知识1.作用2.支持的策略(dnsPolicy)策略名称含义None用于想要自定义 DNS 配置的场景,而且需要和 dnsConfig 配合一起使用De

操作系统: centos7.9 x86_64安装方式: kubeadm。

kubeadm 默认证书为一年，一年过期后会导致 api service 不可用，使用过程中会出现：x509: certificate has expired or is not yet valid.错误。为了防止过期后未及时替换证书的情况出现，建议在部署k8s集群前就编译好100年的kubeadm组件，避免后续重复替换证书步骤已经测试适用于1.28版本,编译机器是麒麟V10 SP2 x86_64架构。

k8s--pod创建、销毁流程

由于这是TO/G项目，当前环境中广泛使用的是CentOS 7操作系统。根据最新出台的相关政策要求，必须对现有的CentOS 7系统进行替换。甲方首选的操作系统为国产麒麟操作系统，这一决策不仅符合政策规定，也有助于推进信息技术领域的自主可控和国产化替代。因为也是首次使用麒麟操作系统。因节前适配机器无法申请,只能先在本地vmware中进行k8s1.28适配工作本篇文章主要以离线部署为主,没有过多的介绍每个roles目录下编写的剧本文件,如果您需要该安装包及部署包讲解，请私信我一一为你解答。

使用并维护过K8S的ops/sre都知道,kubeconfig对于k8s的访问是非常重要。无论是部署，调试还是运维，都需要kubeconfig文件。在通过二进制或者kubeadm方式部署完一套集群后,会在/root/.kube/目录下产生一个config文件,这个文件就是集群的管理文件，如果直接给将该文件给到其他人员肯定不合适，因为管理员的kubeconfig可以干任何事情，注意是任何事情。包括删除节点等高危操作。因此，就涉及到了k8s集群的权限管理。

ConfigMap是Kubernetes中一个关键的配置管理资源，它使得配置文件和参数的管理与容器化应用解耦，从而实现配置的动态调整与应用的无缝更新。通过ConfigMap，开发者可以将配置数据存储在Kubernetes集群中，供应用在运行时访问和使用。在实际应用中，ConfigMap的更新常常是不可避免的，而如何保证这些更新能够快速且无缝地反映到应用中，成为了一个关键问题。特别是在Env变量和Volume挂载的场景中，ConfigMap的热更新机制是否能够顺利应用，直接影响到系统的稳定性与灵活性。

当kubernetes的kube-proxy组件使用iptables模式时,已经创建好的service产生的ip是否能在宿主机中ping通？这也算是初级k8s面试中常问到的一个问题,因此本篇文章就针对该问题进行剖析,看是否能ping通？以及ping不通的原因是什么进行探索。