七叔的博客

Istio 是运行于分布式应用程序之上的非侵入式（无代码入侵）服务网格系统，它的主要目的是为了更好更轻松的解决服务治理问题（Istio 的实现原理是，为每个微服务部署一个 Sidecar（边车），代理微服务之间的所有网络通信。Istio 是一个与 Kubernetes 紧密结合的适用于云原生场景的 Service Mesh 形态的用于服务治理的开放平台。这里的关键字 “治理” 不限于 “微服务治理” 的范畴，任何服务只要服务间有访问，如果需要对服务间的访问做管理，就可以使用 Istio。

当 kubernetes 集群中的某个服务需要升级时，传统的做法是，先将要更新的服务下线，业务停止后再更新版本和配置，然后重新启动并提供服务。如果业务集群规模较大时，这个工作就变成了一个挑战，而且先全部停止，再逐步升级的方式会导致服务较长时间不可用。这个过程面临一个问题，就是在某段时间内，服务是不可用的，对于用户来说是非常不友好的。kubernetes 提供了滚动更新（rolling-update）的方式来解决上述问题。简单来说，滚动更新就是针对多实例服务的一种不中断服务的更新升级方式。

弹性伸缩是根据用户的业务需求和策略，自动 “调整” 其 “弹性资源” 的管理服务。通过弹性伸缩功能，用户可设置定时、周期或监控策略，恰到好处地增加或减少 “弹性资源”，并完成实例配置，保证业务平稳健康运行。在实际工作中，我们常常需要做一些扩容缩容操作，如：电商平台在 618 和双十一搞秒杀活动。由于资源紧张、工作负载降低等都需要对服务实例数进行扩缩容操作。在 k8s 中扩缩容分为两种： 阿里的ack可以实现Node方面的扩容，但是得买人家的云服务，加购一个扩缩容服务。底层用的是OpenStac

灰度发布，也叫金丝雀发布。必须设置该 Annotation 值为true，否则其它规则将不会生效。设置为true表示启用 canary 功能。设置为false表示不启用 canary 功能。表示基于请求头的名称进行灰度发布。alwaysnever表示基于请求头的值进行灰度发布。需要与头配合使用。表示基于权重进行灰度发布。取值范围：0~ 权重总值。若未设定总值，默认总值为 100。表示设定的权重总值。若未设定总值，默认总值为 100。

创建 Secret 资源，Secret 资源中必须包含 tls.crt 和 tls.key 字段。

metadata:spec:rules:http:paths:- path: /backend:service:port:https://xxx.clound.com/yonxxp.scm.scct等URL域名经由外网解析之后，路由到真实企业的Nginx。

是 Ingress 资源中非常重要的路径匹配类型概念，每个路径都必须明确设置该类型，否则无法通过合法性检查。当前支持三种路径类型：Prefix（前缀匹配）当请求路径以 定义的值开头时，就会匹配。例： → 、 都会匹配。Exact（完全匹配）只有当请求路径与 定义的值完全一致时，才会匹配。例： → 只有 会匹配。ImplementationSpecific（实现特定匹配）匹配逻辑由具体的 决定，不同 Ingress 控制器（如 Nginx、Traefik）可能有不同实现；可以作为独立类型处理，也可与

安装复合当前k8s版本的ingress controller，实现ingress的高可用架构、ingress controller的的pod应该部署在专用服务器上，所以一般都使用节点硬亲和性。我们使用1.9.5好了。

维度四层负载均衡七层负载均衡工作层级传输层（TCP/UDP）应用层（HTTP/HTTPS 等）决策依据IP + 端口URL、主机头、请求内容、语言等性能更高，转发逻辑简单稍低，需解析应用层内容场景通用流量转发、保持会话精细化应用路由、内容感知分发在 Kubernetes 中，Ingress 是一种 API 对象，它充当了将外部网络流量路由到 Kubernetes 集群内部服务的入口。它是一个规范化的流量管理方式，可以方便地进行配置和管理。

基本定义：PVC（PersistentVolumeClaim）是 K8s 中用于申请 PV（PersistentVolume）存储资源的对象，代表 Pod 容器所需的持久化存储逻辑卷，声明存储需求与访问模式，由集群自动匹配可用 PV。角色定位：充当 Pod 容器与实际存储之间的 “中介”，让应用可声明所需存储空间与访问模式，解耦 Pod 与具体存储细节。关键约束PVC不能跨命名空间使用，仅能匹配同一命名空间下的 PV。若要绑定特定 PV，PVC 规格需与该 PV 规格完全匹配；

在 k8s 中部署的应用都是以 pod 容器的形式运行的，假如我们部署 MySQL、Redis 等数据库，需要对这些数据库产生的数据做备份。因为 Pod 是有生命周期的，如果 pod 不挂载数据卷，那 pod 被删除或重启后这些数据会随之消失，如果想要长久的保留这些数据就要用到 pod 数据持久化存储。

目标：使用 Deployment 控制器创建 2 个副本，创建 Service 类型为 NodePort 来管理 Deployment 控制器创建的副本。

Service 创建后可直接通过服务名解析，每个服务创建后会在。

Service 是一个固定接入层，客户端可以通过访问 Service 的 IP 和端口访问到 Service 关联的后端 pod。这个服务工作在 K8s依赖于集群之上的一个组件 coredns（集群域名解析服务），service 的名称解析是依赖于 dns 组件的，因此在部署完 k8s 之后需要部署 dns 组件。如果没有coredns，我们会发现通过fqua域名访问Service是不通的。

综上所述，Deployment 控制器是 Kubernetes 中重要的控制器之一，能够提供应用的自动化部署和回滚功能。可以管理和维护应用程序的运行状态，保证应用的稳定性、可用性和可靠性。Kubernetes 中 DaemonSet、Deployment、StatefulSet 这三个核心控制器是我们平时玩的最多的。字段类型说明apiVersionStringAPI 版本kindString资源类型metadataObject元数据String控制器名称String。

对于运行各种负载（如 Service、Job）的中等规模或者大规模的集群来说，出于各种原因，我们需要尽可能提高集群的资源利用率。而提高资源利用率的常规做法是采用优先级方案，即不同类型的负载对应不同的优先级，同时允许集群中的所有负载所需的资源总量超过集群可提供的资源，在这种情况下，当发生资源不足的情况时，系统可以选择释放一些不重要的负载（优先级最低的），保障最重要的负载能够获取足够的资源稳定运行。

在 Kubernetes 中 Pod 是最小的计算单元，而一个 Pod 又由多个容器组成，相当于每个容器就是一个应用，应用在运行期间，可能因为某些意外情况致使程序挂掉。那么如何监控这些容器状态稳定性，保证服务在运行期间不会发生问题，发生问题后进行重启等机制，就成为了重中之重的事情，考虑到这点 kubernetes 推出了。

字段名称取值类型字段说明所属钩子exec<Object>通过命令执行钩子逻辑<[]string>要执行的具体命令（数组格式）httpGet<Object>通过 HTTP 请求触发钩子（注：实际极少用 httpGet 做钩子，exec 更常用）<string>要连接的主机名，默认为 Pod IP<[]Object>自定义 HTTP 请求头<string>请求头字段名<string>请求头字段值<string>HTTP 请求路径HTTP 请求端口<string>

只有。

污点可以使用下列三种进行定义。1、NoSchedule：仅影响 Pod 调度过程，当 Pod 能容忍这个节点污点，就可以调度到当前节点；如果后续节点新增了污点，导致已调度的 Pod 无法容忍，也不会对现存的 Pod 对象产生影响。2、：表示仅当没有其他可用的 Node 时才可以被调度，与 NoSchedule 不同的是，它会更加倾向于不在该 Node 上调度 Pod。3、NoExecute：既影响调度过程，又影响现存的 Pod 对象；

1：目标节点有污点调度不过去2：当我们的节点资源不够用了，所有的资源都满足不了这个需求。

Pod是Kubernetes中的最小调度单元，k8s是通过定义一个Pod的资源，然后在Pod里面运行容器，容器需要指定一个镜像，这样就可以用来运行具体的服务。一个Pod封装一个容器(也可以封装多个容器)，Pod里的容器共享存储、网络等。也就是说，应该把整个pod看作虚拟机，然后每个容器相当于运行在虚拟机的进程。Pod是需要调度到k8s集群的工作节点来运行的，具体调度到哪个节点，是根据 scheduler 调度器实现的。

Label(标签)是Kubernetes系统中另外一个核心概念。一个Label是一个key=value的键值对，其中key与value由用户自己指定。Label可以被附加到各种资源对象上，例如Node、Pod、Service、RC等，在k8s中，大部分资源都可以打标签。一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上。Label通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。

在Kubernetes中，Namespace 可以用来组织和隔离应用资源，而在Namespace中，可以为应用设置资源配额。资源配额可以限制Namespace中某些资源的使用量，包括CPU、内存和存储等。下面是一些常见的Namespace资源配额:1、CPU配额:可以限制一个Namespace中所有Pod使用的CPU配额。2、内存配额:可以限制一个Namespace中所有Pod使用的内存配额。

这是一串 Base64 编码的 JWT 令牌，关联命名空间下的admin-user服务账户；该账户绑定了（集群管理员）权限，意味着用这个 Token 登录 Dashboard 后，你拥有集群所有资源的最高操作权限；

Metrics Server 是Kubernetes集群核心监控数据的聚合器，Metrics Server从Kubelet 收集资源指标，并通过 Merics API在Kubernetes APIServer中提供给缩放资源对象HPA使用。也可以通过Metrics API提供的Kubect ltop查看Pod资源占用情况，再结合HPA从而实现对资源的自动缩放。MetricsServer不对旧值进行存储，且不负责将指标转发到第三方目标。

apiserver、controller-manager、etcd他们也是以容器的形式运行，准确来讲是static pod的方式。让 Pod 之间能互相访问、让 Pod 能访问外部。让外部能访问 Pod这就是 CNI 网络插件 的作用，和 Flannel 功能一样。只允许 A 服务访问 B 服务、禁止外部访问数据库 Pod、不同命名空间不能互通、只允许特定端口通信、企业生产环境必须用这个，不然不安全。接下来检查下是否安装成功了，这个安装之后也是Pod的方式运行，接下来我们访问下Pod。

其实集群外Nginx动态发现K8s Ingress Controller，核心就是解决“动态IP适配”的问题，不用追求最复杂的方案，适合自己公司架构、运维成本低的才是最好的。我公司最终选的是方案三，3个工作节点，配置简单，后续节点扩容时，对Nginx配置无感，实测Pod漂移、扩缩容时，流量完全无中断，稳定性拉满。如果你们在配置过程中遇到问题（比如标签匹配错误、网络不通、健康检查失败），可以在评论区留言，我看到会第一时间回复，帮大家避开坑~

JDK：21。

本文对比分析了LVS、F5和SLB三种主流负载均衡方案。LVS是开源四层负载均衡，性能优异但需专业运维；F5作为商用硬件，提供全栈负载均衡和安全防护，适合高要求场景；SLB是云托管服务，弹性灵活且运维简单。文章从产品类型、性能、成本等维度进行详细对比，并给出选型建议：开源架构选LVS，核心业务选F5，云原生场景选SLB。实际应用中，多层级组合方案（如LVS+Nginx）往往能实现最优效果。

本文探讨了企业级K8s集群入口流量架构设计，提出"外层Nginx负载均衡+内层独立IngressController"的双层架构方案。该方案通过分层解耦实现流量接入、路由转发和安全防护的精细化管控，外层Nginx负责全局流量接入和安全防护，内层IngressController专注应用级路由分发。文章详细分析了二者的核心差异、多应用独立部署的价值，并提供了完整的动态伸缩配置方案，包括命名空间隔离、Deployment配置、Service对接等关键实现。该架构已在多个ERP项目中验证，能有

一句话概括二者的关系：Service是K8s流量管理的“基础层”，解决Pod的稳定访问问题；Ingress是“高级层”，基于Service实现外部流量的精细化管控。实战中，需根据服务类型、访问需求，合理搭配二者，构建高效、可靠的K8s流量架构。如果需要Ingress Controller的部署教程、高级配置技巧（如限流、SSL配置），可以留言交流，后续会补充对应的实操内容。

本文详细解析了Kubernetes中kubectl get replicaset命令的用法，并与kubectl get pods进行对比。replicaset作为Pod的管理控制器，关注副本数等策略层面信息，而pods则展示具体容器实例的运行状态。文章介绍了replicaset命令的常用形式、输出字段解读及核心使用场景，强调了两者在管理层级、关注重点上的差异。最佳实践建议先检查replicaset确认策略生效，再查看pods定位具体问题，二者配合使用能有效提升K8s集群运维效率。

摘要： Kubernetes中Pod内存请求（MemoryRequest）和内存限制（MemoryLimit）是资源管理的核心概念，二者功能不同但常被混淆。内存请求是调度依据，确保节点有足够资源；内存限制是运行时约束，防止内存溢出（OOM）。配置时需遵循请求≤限制，单位避免混用。生产环境需监控内存使用，合理设置缓冲（如限制为峰值的1.2~1.5倍），并避免请求=限制导致的资源浪费。常见问题包括Pod因请求过高无法调度、限制过低触发OOM等，解决方案包括调整配置、优化代码或扩容节点。通过理解调度逻辑（CGro

只展示Pod名称、镜像、资源限制# 结合标签筛选，只看prod环境的Pod其实命令的核心逻辑很简单，关键在于掌握-o参数对应的不同输出格式，以及辅助参数的灵活搭配。日常运维中，不用死记硬背所有参数，记住“场景对应格式”即可：排查问题用yaml，快速查看用wide，脚本处理用jsonpath，批量操作用name。多在集群中实操几次，自然就能形成肌肉记忆，真正做到“玩转”这条基础命令。最后提醒一句：K8s命令的参数都可以通过查看，遇到忘记的参数时，直接查帮助文档最靠谱～

本次故障本质是配置文件的语法疏漏和逻辑不匹配，看似都是细节问题，却在实操中导致了Pod反复崩溃，这类问题在新手运维中尤为常见。启动命令需严谨：Shell命令（如sleep、nginx）的语法、格式必须规范，重点注意参数与命令的空格分离、关键字拼写，同时确保命令能触发前台进程——K8s容器的生命周期与前台进程强绑定，后台进程会直接导致容器退出。探针配置要适配业务逻辑需根据容器实际启动时长合理设置，过短会导致误判重启，过长则无法及时检测容器故障；

1. K8s Pod创建后，Command/Args属于不可修改字段，直接修改会触发更新限制报错，需通过“删除旧Pod+重建新Pod”解决。2. 临时调试场景可使用上述方法，生产环境优先采用Deployment管理Pod，支持参数平滑更新，提升运维效率。3. 日常操作中，建议先检查YAML文件中的参数拼写、格式，避免因低级错误导致Pod创建失败或需要重复修改。如果遇到其他K8s Pod更新相关问题，欢迎在评论区交流讨论！

Ingress：对外承接域名流量，实现七层路由、负载均衡与灰度调试，是服务对外暴露的“门户”。Service：对内提供固定访问入口，解决Pod动态漂移问题，实现服务发现与流量分发，是流量转发的“中转站”。Deployment：负责应用编排，实现Pod的创建、零停机更新、故障自愈与资源管控，是服务稳定运行的“管家”。Pod：作为最小运行单元，承载业务容器与核心配置，是流量的最终“落地载体”。理解四层资源的关联关系、核心配置与运行链路，是掌握K8s微服务部署、运维与故障排查的关键。

官网地址Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。Pod是一组（一个或多个）容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。简言之如果用 Docker 的术语来描述，Pod 类似于共享名字空间并共享文件系统卷的一组容器。Docker面向的是一个又一个容器。K8s管理的是一个又一个的Pod，他可能对应多个容器。

本文系统解析了Kubernetes中kubectl exec -it nginx -- bash命令的核心用法。该命令用于进入nginx Pod容器内部启动bash终端，主要应用于故障排查、文件查看等运维场景。文章从命令结构、参数原理、实战变体（多容器/跨命名空间/非交互式执行）和错误排查四个维度展开，重点解析了-it交互式终端、--分隔符等关键细节，并针对常见错误提供了解决方案。掌握该命令是K8s运维的基础能力，理解其与K8s API的交互机制，能够灵活应对不同容器镜像和Pod状态的运维需求。