The Good Student！ - kubernetes
type: channel
link: https://www.hxy.bj.cn/category/kubernetes/
items: Kubernetes灰度发布实战
items: Kubernetes 调度器介绍-Pod调度
items: Ingress-Nginx部署
items: KubeSphere平台安装
items: k8s核心概念详解图
items: K8S 的资源（清单/类型）
items: k8s搭建私有镜像仓库Harbor
items: 深入了解 Kubernetes Pod 的状态
items: k8s-helm
items: 在 Kubernetes 集群上安装/升级 Rancher

Kubernetes灰度发布实战
type: item
date: 2025-08-04T16:57:00+08:00
description: AI摘要 本文详细介绍了Kubernetes中的灰度发布策略，包括灰度发布的概念、优势、实现方案和最佳实践。文章通过示例代码展示了基于Service+Deployment标签选择、Ingress Controller和Istio Service Mesh的灰度发布实现方法，并提供了监控配置、发布策略、自动化回滚和用户细分策略等最佳实践。最后，文章讨论了常见问题及其解决方案，强调了灰度发布在现代应用部署中的重要性。 此内容根据文章生成，仅用于文章内容的解释与总结 Kubernetes灰度发布实战指南：让你的应用更新更安全在微服务架构盛行的今天，应用的频繁更新已经成为常态。然而，如何在保证业务稳定的前提下，安全地发布新版本，一直是运维和开发团队面临的重要挑战。今天我们来深入探讨Kubernetes中的灰度发布策略，让你的应用更新更加安全可控。什么是灰度发布？灰度发布（Canary Deployment），也称为金丝雀发布，是一种渐进式的部署策略。它的核心思想是先将新版本部署到一小部分用户或服务器上，观察其运行情况，如果一切正常，再逐步扩大新版本的覆盖范围，直到完全替换旧版本。这种策略的名称来源于矿工使用金丝雀检测矿井中有毒气体的做法——如果金丝雀出现异常，矿工就知道环境有危险。同样，如果新版本在小范围内出现问题，我们可以及时发现并回滚，避免影响全部用户。为什么选择灰度发布？1. 降低风险传统的蓝绿部署虽然可以快速切换，但如果新版本有问题，影响范围是100%。而灰度发布可以将风险控制在可接受范围内。2. 实时监控可以通过监控小部分用户的反馈来评估新版本的性能和稳定性。3. 快速回滚一旦发现问题，可以立即停止流量导向新版本，将用户请求重新路由到稳定版本。4. 用户体验优化可以根据用户反馈来调整新版本，确保最终发布的版本质量更高。Kubernetes中的灰度发布实现方案方案一：基于Service + Deployment的标签选择这是最基础的灰度发布方式，通过控制不同版本Pod的数量来实现流量分配。# 稳定版本 Deployment apiVersion:apps/v1 kind:Deployment metadata: name:app-stable spec: replicas:9 selector: matchLabels: app:myapp version:stable template: metadata: labels: app:myapp version:stable spec: containers: -name:app image:myapp:v1.0 ports: -containerPort:8080 --- # 金丝雀版本 Deployment apiVersion:apps/v1 kind:Deployment metadata: name:app-canary spec: replicas:1 selector: matchLabels: app:myapp version:canary template: metadata: labels: app:myapp version:canary spec: containers: -name:app image:myapp:v2.0 ports: -containerPort:8080 --- # Service 配置 apiVersion:v1 kind:Service metadata: name:app-service spec: selector: app:myapp ports: -port:80 targetPort:8080 type: ClusterIP在这个配置中，Service会将流量分发到所有带有app: myapp标签的Pod上。由于稳定版本有9个副本，金丝雀版本有1个副本，所以大约10%的流量会被分发到新版本。方案二：使用Ingress Controller实现更精细的流量控制对于需要更精确流量控制的场景，可以使用Ingress Controller（如Nginx Ingress）的高级功能。# 主要的Ingress规则 apiVersion:networking.k8s.io/v1 kind:Ingress metadata: name:app-ingress annotations: nginx.ingress.kubernetes.io/canary:"false" spec: rules: -host:myapp.example.com http: paths: -path:/ pathType:Prefix backend: service: name:app-stable-service port: number:80 -…

Kubernetes 调度器介绍-Pod调度
type: item
date: 2025-07-28T10:01:00+08:00
description: AI摘要 Kubernetes调度器负责将Pod放置到合适的节点上，以便节点上的Kubelet能够运行这些Pod。调度器通过监测机制发现未调度的Pod，并根据资源需求、节点选择器、节点亲和性、Pod亲和/反亲和性等原则进行调度。kube-scheduler是Kubernetes集群的默认调度器，负责选择最佳节点运行Pod。调度器的调度决策考虑因素包括资源请求、硬件/软件/策略限制、亲和及反亲和要求、数据局部性和负载间的干扰等。用户可以通过节点标签、节点隔离/限制、nodeSelector、亲和性与反亲和性、nodeName和Pod拓扑分布约束等方法来控制Pod的调度。 此内容根据文章生成，仅用于文章内容的解释与总结 调度概述在 Kubernetes 中，调度是指将 Pod 放置到合适的节点上，以便对应节点上的 Kubelet 能够运行这些 Pod。调度概览调度器通过 Kubernetes 的监测（Watch）机制来发现集群中新创建且尚未被调度到节点上的 Pod。 调度器会将所发现的每一个未调度的 Pod 调度到一个合适的节点上来运行。 调度器会依据下文的调度原则来做出调度选择。如果你想要理解 Pod 为什么会被调度到特定的节点上， 或者你想要尝试实现一个自定义的调度器，这篇文章将帮助你了解调度。当多个调度规则同时存在时，Kubernetes 会按照以下优先级顺序处理：资源需求：CPU/内存请求是最基本的筛选条件节点选择器（nodeSelector）：简单的标签匹配节点亲和性（required）：必须满足的节点条件Pod 亲和/反亲和性（required）：必须满足的 Pod 关系条件kube-schedulerkube-scheduler 是 Kubernetes 集群的默认调度器，并且是集群 控制面 的一部分。 如果你真的希望或者有这方面的需求，kube-scheduler 在设计上允许你自己编写一个调度组件并替换原有的 kube-scheduler。Kube-scheduler 选择一个最佳节点来运行新创建的或尚未调度（unscheduled）的 Pod。 由于 Pod 中的容器和 Pod 本身可能有不同的要求，调度程序会过滤掉任何不满足 Pod 特定调度需求的节点。 或者，API 允许你在创建 Pod 时为它指定一个节点，但这并不常见，并且仅在特殊情况下才会这样做。在一个集群中，满足一个 Pod 调度请求的所有节点称之为可调度节点。 如果没有任何一个节点能满足 Pod 的资源请求， 那么这个 Pod 将一直停留在未调度状态直到调度器能够找到合适的 Node。调度器先在集群中找到一个 Pod 的所有可调度节点，然后根据一系列函数对这些可调度节点打分， 选出其中得分最高的节点来运行 Pod。之后，调度器将这个调度决定通知给 kube-apiserver，这个过程叫做绑定。在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、 亲和以及反亲和要求、数据局部性、负载间的干扰等等。kube-scheduler 中的节点选择kube-scheduler 给一个 Pod 做调度选择时包含两个步骤：过滤打分过滤阶段会将所有满足 Pod 调度需求的节点选出来。 例如，PodFitsResources 过滤函数会检查候选节点的可用资源能否满足 Pod 的资源请求。 在过滤之后，得出一个节点列表，里面包含了所有可调度节点；通常情况下， 这个节点列表包含不止一个节点。如果这个列表是空的，代表这个 Pod 不可调度。在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的节点。 根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。最后，kube-scheduler 会将 Pod 调度到得分最高的节点上。 如果存在多个得分最高的节点，kube-scheduler 会从中随机选取一个。支持以下两种方式配置调度器的过滤和打分行为：调度策略 允许你配置过滤所用的 断言（Predicates） 和打分所用的 优先级（Priorities）。调度配置 允许你配置实现不同调度阶段的插件， 包括：QueueSort、Filter、Score、Bind、Reserve、Permit 等等。 你也可以配置 kube-scheduler 运行不同的配置文件。将 Pod 指派给节点你可以约束一个 Pod 以便限制其只能在特定的节点上运行， 或优先在特定的节点上运行。有几种方法可以实现这点， 推荐的方法都是用标签选择算符来进行选择。 通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 Pod 分散到节点上， 而不是将 Pod 放置在可用资源不足的节点上等等）。但在某些情况下，你可能需要进一步控制 Pod 被部署到哪…

Ingress-Nginx部署
type: item
date: 2025-05-10T22:02:48+08:00
description: Ingress-Nginx 基本概念与核心功能Ingress-Nginx 是 Kubernetes 生态中最流行的 Ingress Controller 实现之一，用于管理集群外部到内部服务的 HTTP (S) 流量。它本质上是一个基于 Nginx 的负载均衡器，通过 Kubernetes 的 Ingress 资源进行配置。1. 基本概念1.1 Ingress vs Ingress ControllerIngress：Kubernetes 的 API 对象，定义了外部访问集群内服务的规则（如域名、路径、TLS 配置等）。Ingress Controller：具体实现这些规则的组件（如 Nginx、Traefik、HAProxy 等），负责将流量转发到后端服务。1.2 Ingress-Nginx 的角色作为 Kubernetes 集群的 "前门"，接收所有外部 HTTP (S) 流量。根据 Ingress 资源的配置，将请求路由到对应的后端 Service。提供负载均衡、SSL 终止、路径重写、访问控制等功能。2. 流程逻辑2.1 组件交互流程客户端请求 → 负载均衡器（如云厂商 LB 或 NodePort） → Ingress-Nginx Pod → 根据 Ingress 规则 → 后端 Service → Pod2.2 关键步骤详解部署 Ingress-Nginx：在集群中部署 Ingress-Nginx Controller（通常作为 DaemonSet 或 Deployment）。创建 Service（类型为 LoadBalancer 或 NodePort）暴露 Controller。定义 Ingress 规则：yamlapiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: backend-service port: number: 8080规则生效：Ingress-Nginx 监控 Ingress 资源的变化，动态更新 Nginx 配置。当请求到达时，根据 host 和 path 匹配规则，转发到对应 Service。3. 使用场景3.1 域名路由将不同域名的请求路由到不同服务：yamlspec: rules: - host: api.example.com http: ... # 路由到 API 服务 - host: www.example.com http: ... # 路由到前端服务3.2 路径前缀路由根据 URL 路径将请求分发到不同服务：yamlspec: rules: - host: example.com http: paths: - path: /api backend: { service: { name: api-service } } - path: /web backend: { service: { name: web-service } }3.3 SSL/TLS 终止在 Ingress 层处理 HTTPS 请求，卸载 SSL 证书管理：yamlspec: tls: - hosts: - example.com secretName: tls-secret # 包含证书和私钥的 Secret3.4 负载均衡与流量控制通过 Ingress-Nginx 实现请求限流、重试策略、加权负载均衡等。3.5 微服务网关作为微服务架构的统一入口，处理认证、授权、API 聚合等功能。4. 优势与最佳实践4.1 优势声明式配置：通过 Ingress 资源定义规则，无需直接修改 Nginx 配置。动态更新：配置变更实时生效，无需重启服务。扩展性：支持丰富的注解（Annotations）扩展功能。5.Ingress-Nginx部署5.1部署Ingress-Nginx下面配置内容是已经替换好的（可以直接CV使用），在 K8S 主节点上创建ingress-deploy.yaml文件内容，内容如下，然后进行kubectl apply -f ingress-deploy.yaml 就可以了！[root@k8s-master01 k8s-demo]# cat ingress-deploy.yaml apiVersion: v1 kind: Namespace metadata: labels: app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/name: ingress…

KubeSphere平台安装
type: item
date: 2025-05-03T23:53:00+08:00
description: KubeSphere简介个人感觉推荐：学习使用kubesphere，企业使用rancherKubeSphere 是一款功能强大的容器管理平台，以下是其简介：基本信息开源项目：基于 Apache-2.0 授权协议开源，由 Google Go、Groovy、HTML/CSS 和 Shell 等多种编程语言开发。基础架构：以 Kubernetes 为内核，架构具有即插即用特性，可运行在私有云、公有云、混合云等多种环境，支持多云与多集群的统一管理。功能特性全栈 IT 自动化：提供从 Kubernetes 集群搭建到运维的全栈 IT 自动化能力，支持在线和离线安装、升级与扩容。可视化资源管理：提供可视化的 Kubernetes 资源管理界面，用户可通过向导式界面轻松创建和管理各种 K8s 资源。强大的 DevOps 功能：内置基于 Jenkins 的 DevOps 系统，支持图形化和脚本两种方式的 CI/CD 流水线构建，还提供 S2I 和 B2I 等 CD 工具。微服务治理出色：基于 Istio 提供可视化无代码侵入的灰度发布、熔断、流量治理等功能，同时支持分布式 Tracing。多租户管理：提供基于角色的细粒度统一认证，支持对接企业 LDAP/AD，实现多层级的权限管理。可观察性强：提供集群、工作负载、Pod、容器等多维度的监控，支持基于多租户的日志查询与日志收集，提供节点与应用层级的告警与通知功能。基础设施管理全面：支持 Kubernetes 节点管理、节点扩容与集群升级，支持对接多种存储系统，提供可视化运维管理 PVC、StorageClass 的功能，并支持 CSI 插件对接云平台存储。网络管理灵活：提供租户网络隔离与 K8s NetworkPolicy 管理功能，支持 Calico、Flannel 等多种网络插件，并提供 Porter LB 用于暴露物理环境 K8s 集群的 LoadBalancer 服务。支持 GPU 资源管理：可运行 TensorFlow 等 ML 框架，为 AI 和大数据应用提供支持。技术架构：采用前后端分离设计，后端各个功能组件可通过 REST API 对接外部系统，这种设计让其能灵活运行在各种 Kubernetes、私有云、公有云、VM 或物理环境之上。应用场景助力业务数字化转型：帮助企业一步升级容器架构，适应数字化转型需求。降低运维复杂度：通过多维管控 Kubernetes，让运维工作更加轻松。推动企业 DevOps 落地：实现敏捷开发与自动化运维，提升开发和运维效率。升级云原生架构：提供灵活的微服务解决方案，助力企业构建云原生架构。释放硬件最大效能：基于物理环境构建全栈容器架构，充分利用硬件资源。主机名ip角色k8s-master01100.100.157.10k8s-master01/nfs-serverk8s-work01100.100.157.11k8s-work01/nfs-clientk8s-work02100.100.157.12k8s-work02/nfs-client一、NFS安装1、所有服务器节点安装NFS服务参考nfs安装手册2、配置KubeSphere共享的目录#步骤一：创建共享目录 mkdir -p /root/hxy/nfs/data/kubesphere #步骤二：在/etc/exports文件中加入下面的行 /root/hxy/nfs/data/kubesphere *(insecure,rw,sync,no_root_squash) #步骤三：重启NFS服务 systemctl restart rpcbind && systemctl enable rpcbind systemctl restart nfs && systemctl enable nfs #步骤四：查看配置是否生效 exportfs -r exportfs #步骤五：其他集群节点上查看配置是否生效 showmount -e 100.100.157.103、部署NFS Subdir External Provisioner 插件作用：因为NFS没有可以提供动态卷供应的能力，安装NFS Subdir External Provisioner 插件，NFS 能为 KubeSphere 提供动态卷供应能力。当有新的 PersistentVolumeClaim（PVC）创建时，系统可自动根据 StorageClass 的配置，在 NFS 服务器上创建对应的存储卷并挂载到需要的容器中，提高了存储资源的分配效率和灵活性。3.1 安装步骤#步骤一：创建安装目录 mkdir -p /opt/k8s/kubesphere && cd /opt/k8s/kubesphere #步骤二：下载压缩包 wget https:…

k8s核心概念详解图
type: item
date: 2025-04-28T10:14:00+08:00
description: k8s核心知识概念详解图

K8S 的资源（清单/类型）
type: item
date: 2025-04-23T22:34:00+08:00
description: K8S 的资源清单参数名类型字段说明apiVersionStringK8S APl 的版本，可以用 kubectl api versions 命令查询kindStringyam 文件定义的资源类型和角色metadataObject元数据对象，下面是它的属性metadata.nameString元数据对象的名字，比如 pod 的名字metadata.namespaceString元数据对象的命名空间SpecObject详细定义对象spec.containers[]list定义 Spec 对象的容器列表spec.containers[].nameString为列表中的某个容器定义名称spec.containers[].imageString为列表中的某个容器定义需要的镜像名称spec.containers[].imagePullPolicystring定义镜像拉取策略，有 Always、Never、IfNotPresent 三个值可选 - Always（默认）：意思是每次都尝试重新拉取镜像 - Never：表示仅适用本地镜像 - IfNotPresent：如果本地有镜像就使用本地镜像，没有就拉取在线镜像。spec.containers[].command[]list指定容器启动命令，因为是数组可以指定多个，不指定则使用镜像打包时使用的启动命令。spec.containers[].args[]list指定容器启动命令参数，因为是数组可以指定多个。spec.containers[].workingDirstring指定容器的工作目录spec.containers[].volumeMounts[]list指定容器内部的存储卷配置spec.containers[].volumeMounts[].namestring指定可以被容器挂载的存储卷的名称spec.containers[].volumeMounts[].mountPathstring指定可以被容器挂载的存储卷的路径spec.containers[].volumeMounts[].readOnlystring设置存储卷路径的读写模式，ture 或者 false，默认是读写模式spec.containers[].ports[]list指定容器需要用到的端口列表spec.containers[].ports[].namestring指定端口的名称spec.containers[].ports[].containerPortstring指定容器需要监听的端口号spec.containers[].ports[].hostPortstring指定容器所在主机需要监听的端口号，默认跟上面 containerPort 相同，注意设置了 hostPort 同一台主机无法启动该容器的相同副本（因为主机的端口号不能相同，这样会冲突）spec.containers[].ports[].protocolstring指定端口协议，支持 TCP 和 UDP，默认值为 TCPspec.containers[].env[]list指定容器运行前需设置的环境变量列表spec.containers[].env[].namestring指定环境变量名称spec.containers[].env[].valuestring指定环境变量值spec.containers[].resourcesObject指定资源限制和资源请求的值（这里开始就是设置容器的资源上限）spec.containers[].resources.limitsObject指定设置容器运行时资源的运行上限spec.containers[].resources.limits.cpustring指定 CPU 的限制，单位为 Core 数，将用于 docker run –cpu-shares 参数spec.containers[].resources.limits.memorystring指定 mem 内存的限制，单位为 MIB、GiBspec.containers[].resources.requestsObject指定容器启动和调度时的限制设置spec.containers[].resources.requests.cpustringCPU请求，单位为core数，容器启动时初始化可用数量spec.containers[].resources.requests.memorystring内存请求，单位为MIB、GiB，容器启动的初始化可用数量spec.restartPolicystring定义 pod 的重启策略，可选值为 Always、OnFailure、Never，默认值为 Always。 - Always：pod 一旦终止运行，则无论容器是如何终止的，kub…

k8s搭建私有镜像仓库Harbor
type: item
date: 2025-04-18T14:04:00+08:00
description: Harbor私有镜像仓库无坑搭建一、介绍Docker容器应用的开发和运行路不开可靠的镜像管理，虽然Docker官方也提供了公共的镜像仓库，但是从安全和效率等方面考虑，部署我们私有环境的Registry也是非常必要的。 Harbor是由VMware公司开源的企业级的Docker Registry管理项目，它包括权限管理(RBAC)、LDAP、日志审核、管理界面、自我注册、镜像复制和中文支持等功能。二、组件用于部署 Harbor 的 Docker Compose 模板位于 /Deployer/docker-compose.yml. 打开这个模板文件，会发现 Harbor 由 5 个容器组成：proxy：由 Nginx 服务器构成的反向代理。registry：由 Docker 官方的开源 registry 镜像构成的容器实例。ui：即架构中的 core services, 构成此容器的代码是 Harbor 项目的主体。mysql：由官方 MySql 镜像构成的数据库容器。log: 运行着 rsyslogd 的容器，通过 log-driver 的形式收集其他容器的日志。这几个容器通过 Docker link 的形式连接在一起，这样，在容器之间可以通过容器名字互相访问。对终端用户而言，只需要暴露 proxy (即 Nginx)的服务端口。三、工作原理假设我们将 Harbor 部署在主机名为 registry.abcdocker.com 的虚机上。用户通过 docker login 命令向这个 Harbor 服务发起登录请求:docker login registry.abcdocker.com当用户输入所需信息并点击回车后，Docker 客户端会向地址“registry.abcdocker.com/v2/” 发出 HTTP GET 请求。Harbor 的各个容器会通过以下步骤处理：(1)Docker login(a) 首先，这个请求会由监听 80 端口的 proxy 容器接收到。根据预先设置的匹配规则，容器中的 Nginx会将请求转发给后端的 registry 容器；(2) 在 registry 容器一方，由于配置了基于 token 的认证，registry 会返回错误代码 401，提示 Docker客户端访问 token 服务绑定的 URL。在 Harbor 中，这个 URL 指向 Core Services；(3) Docker 客户端在接到这个错误代码后，会向token服务的URL发出请求，并根据HTTP协议的BasicAuthentication 规范，将用户名密码组合并编码，放在请求头部(header)；(4)类似地，这个请求通过 80 端口发到 proxy 容器后，Nginx 会根据规则把请求转发给 ui 容器，ui 容器监听 token 服务网址的处理程序接收到请求后，会将请求头解码，得到用户名、密码；(5) 在得到用户名、密码后，ui 容器中的代码会查询数据库，将用户名、密码与 mysql 容器中的数据进行比对(注:ui 容器还支持 LDAP 的认证方式，在那种情况下 ui 会试图和外部 LDAP 服务进行通信并校验用户名/密码)。比对成功，ui 容器会返回表示成功的状态码， 并用密钥生成 token，放在响应体中返回给 Docker 客户端。这个过程中组件间的交互过程如下图所示三、安装环境ip主机名harbor-server100.100.157.10k8s-master01harbor-client100.100.157.11k8s-work01harbor-client100.100.157.12k8s-work02Harbor 2种安装方式1.离线安装 wget https://github.com/goharbor/harbor/releases/download/v2.12.1/harbor-offline-installer-v2.12.1.tgz tar xf harbor-offline-installer-v2.12.1.tgz 2.在线安装 $ wget https://storage.googleapis.com/harbor-releases/harbor-online-installer-v1.5.2.tgz $ tar xf harbor-online-installer-v1.5.2.tgz[root@harbor harbor]# head harbor.yml需：cp harbor.yml.tmpl harbor.yml修改hostname ：ip地址修改port：默认端口号注释https本次我们使用离线安装，安装包在上面$ tar xf harbor-offline-installe…

深入了解 Kubernetes Pod 的状态
type: item
date: 2025-04-08T23:13:00+08:00
description: 深入了解 Kubernetes Pod 的状态背景：在 Kubernetes 中，Pod 是部署和管理应用的最小单位。理解 Pod 的各种状态、它们的意义以及如何排查异常状态，对于我们日常运维和故障排查至关重要。在这篇文章中，我们将介绍 Kubernetes Pod 的各种状态，结合具体实例，帮助大家更好地理解和排查 Pod 异常。一、Pod的常见状态Kubernetes 中，Pod 通过不同的状态反映其生命周期中的不同阶段。下面是 Kubernetes 中 Pod 的常见状态：Pending(待定)状态描述：Pod 被创建但还没有被调度到某个节点上，或者它的容器还没有完全启动。通常出现这个状态的原因是资源不足（如内存、CPU）或者调度问题。常见原因：1、节点资源不足，导致 Pod 无法调度。2、调度器（Scheduler）还未选择节点来运行 Pod。3、Pod 的镜像在节点上尚未拉取完毕。查看pending状态的podkubectl get pods --field-selector=status.phase=Pending排查方法：1、查看pod事件信息： kubectl describe pod pod-name -n namespace 2、查看集群资源是否足够： kubectl describe node node-nameRunning(运行中)状态描述：Pod 已经被调度到节点并且至少有一个容器正在运行。这个状态意味着 Pod 已经在正常运行状态，可以处理请求。常见原因：这是 Pod 生命周期中的正常状态，表示 Pod 的容器已经成功启动并处于运行状态排查方法：1、使用以下命令查看 Pod 是否在 Running 状态 kubectl get pods 2、如果 Pod 处于 Running 状态但应用出现问题，可以通过 kubectl logs 查看容器日志： kubectl logs <pod-name>Succeeded(成功)状态描述：Pod 中的所有容器都已成功运行并且正常退出。当所有容器的退出状态码为 0 时，Pod 会进入 Succeeded 状态。常见原因：pod中的容器已经完成它的工作并且退出，通常用于一次性任务（如批处理任务）排除方法：1、如果 Pod 处于 Succeeded 状态，但你期望它仍在运行，可以通过查看容器的退出码来判断： kubectl describe pod <pod-name> 查看容器的退出码和日志，判断是否是由于应用异常导致提前退出。 failed（失败）状态描述：Pod 中的容器遇到错误并且退出，退出码不为 0。Pod 在运行期间发生了错误或者容器无法启动，因此进入 Failed 状态。常见原因：1、容器在启动时发生错误，通常是由于配置问题、依赖问题或应用崩溃等。2、容器多次重启并且超过了重启限制。排查原因：1、查看 Pod 事件： kubectl describe pod <pod-name> 查找是否有错误事件，比如镜像拉取失败、资源不足等。 2、查看容器日志： kubectl logs <pod-name> 查找容器退出时的日志信息，定位容器崩溃的原因。 3、查看 Pod 的重启次数： kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[0].restartCount}' 如果重启次数过多，说明容器不断崩溃，可以尝试查看容器日志以排查问题。crashloopbackoff（崩溃循环）状态描述：Pod 中的容器崩溃后尝试重启，但一直处于重启失败的状态，进入 CrashLoopBackOff 状态。常见原因：1、容器内的应用崩溃，容器无法正常启动。2、容器的启动命令或配置存在错误。3、容器的依赖环境没有准备好，比如数据库连接失败、网络问题等。排查方法： 1、查看 Pod 事件： kubectl describe pod <pod-name> 查看 Pod 的事件日志，看看是否有关于容器重启失败的错误信息。 2、查看容器日志： kubectl logs <pod-name> 查看容器崩溃时的日志信息，查找异常原因。 3、临时进入 Pod 调试： kubectl exec -it <pod-name> -- /bin/bash 如果容器启动失败，可以进入容器内部查看配置文件、运行环境等，进一步排查。unknown（未知）状态描述：Pod 的状态无法被 Kubernetes 控制平面确定，通常发生在节点无法与控制平面通信时。这个状态意味着集群的某个组件无法获取 Pod 的状态。常见原因：1、节点的网络或状态与控制平面断开连接，导致 Pod 的状态无法同步。2、控制平面出现问题，无法从节点获…

k8s-helm
type: item
date: 2025-04-08T14:13:00+08:00
description: 前言Helm的官方网站、Helm的github地址在没有使用Helm之前，向kubernetes部署应用，我们依次需要编写deployment、service、ingress等yaml文件，然后还需要依次进行部署，步骤比较繁琐。随着项目的微服务化，复杂的应用在容器中部署以及管理显得较为复杂。因此Helm通过打包的方式生成Char模板，然后install Char模板生成release，支持发布的版本管理和控制，很大程度上简化了kubernetes应用的部署和管理。Helm简介Helm的本质就是让k8s的应用管理（Deployment、Service）可配置，能够动态生成。通过动态生成k8s资源清单文件，然后调用kubectl命令自动执行k8s资源部署。我们可以将Helm看作Kubernetes下的apt-get/yum。Helm是Deis 开发的一个用于kubernetes的包管理器。每个包称为一个Chart，一个Chart是一个目录（一般情况下会将目录进行打包压缩，形成name-version.tgz格式的单一文件，方便传输和存储）。对于应用发布者而言，可以通过Helm打包应用，管理应用依赖关系，管理应用版本并发布应用到软件仓库。对于使用者而言，使用Helm后不用需要了解Kubernetes的yaml语法并编写应用部署文件，可以通过Helm下载并在kubernetes上安装需要的应用，同时进行少量的配置即可。除此以外，Helm还提供了kubernetes上的软件部署，删除，升级，回滚应用的强大功能。Helm还可以结合Jenkins进行CI、CD进行自动化、流水线构建项目，可以将我们大量重复的步骤省略，节约时间。Helm的作用有以下几点：快速安装常用应用：许多大公司都有helm仓库，为我们提供了许多优质的应用，可以直接拉取安装，如快速部署Redis集群、安装Jenkins等。多环境部署：通常我们需要多套环境，如开发环境、测试环境、生产环境等，helm可以通模板+变量的形式实现快速部署。运维与开发隔离：运维人员治理k8s资源，写部署模板及默认设置；开发职员只需要提供少量设置即可，把精力主要集中在开发上。Helm的基本原理Helm中有四大基本概念：helm客户端、Char、Repository、Releasehelm客户端：主要是命令行，负责管理本地的Charts、repositories，发送Chart，实例安装、查询、卸载等操作。Chart：是创建一个应用的信息集合，包括各种Kubernetes对象的配置模板、参数定义、依赖关系、文档说明等，形成一个压缩包.tar。Char是应用部署的自包含逻辑单元。可以将Chart想象成apt、yum中的软件安装包，同时Char模板可以发布到专门的repository。Repository: Chart仓库。类似于docker的镜像仓库，可以使用Harbor作为Chart的仓库。Release：release是Chart运行的实例，使用helm install命令在Kubernetes集群中部署的Chart就生成了一个Release。一个Chart能够多次安装到同一个集群，每次安装都是一个Release。Release基于名称空间进行隔离。Helm安装方法 1：通过脚本自动安装（推荐）curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh说明：此脚本会自动下载最新 Helm 二进制文件并安装到 /usr/local/bin 目录。适用于 Linux/macOS 系统。方法 2：手动下载二进制文件从 Helm GitHub Release 下载对应系统的二进制包（如 helm-v3.x.x-linux-amd64.tar.gz）。解压并移动到可执行路径：tar -zxvf helm-v3.x.x-linux-amd64.tar.gz sudo mv linux-amd64/helm /usr/local/bin/helm验证安装：helm version，输出类似 version.BuildInfo{Version:"v3.x.x"} 表示成功。配置 Helm 仓库（添加一个就行，阿里云就好）添加官方仓库：helm repo add stable https://charts.helm.sh/stable国内镜像加速helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts更新仓库索引helm repo…

在 Kubernetes 集群上安装/升级 Rancher
type: item
date: 2025-04-08T13:53:00+08:00
description: 什么是 Rancher？参考：官方文档教程Rancher 是一个 Kubernetes 管理工具，让你能在任何地方和任何提供商上部署和运行集群。Rancher 可以创建来自 Kubernetes 托管服务提供商的集群，创建节点并安装 Kubernetes，或者导入在任何地方运行的现有 Kubernetes 集群。Rancher 基于 Kubernetes 添加了新的功能，包括统一所有集群的身份验证和 RBAC，让系统管理员从一个位置控制全部集群的访问。此外，Rancher 可以为集群和资源提供更精细的监控和告警，将日志发送到外部提供商，并通过应用商店（Application Catalog）直接集成 Helm。如果你拥有外部 CI/CD 系统，你可以将其与 Rancher 对接。没有的话，你也可以使用 Rancher 提供的 Fleet 自动部署和升级工作负载。Rancher 是一个 全栈式 的 Kubernetes 容器管理平台，为你提供在任何地方都能成功运行 Kubernetes 的工具。在 Kubernetes 集群上安装/升级 Rancher备注本安装指南假定你使用的是 Helm 3。要设置 Rancher：添加 Helm Chart 仓库为 Rancher 创建命名空间选择 SSL 配置安装 cert-manager（除非你自带证书，否则 TLS 将在负载均衡器上终止）使用 Helm 和你选择的证书选项安装 Rancher验证 Rancher Server 是否部署成功保存选项1. 添加 Helm Chart 仓库[](https://ranchermanager.docs.rancher.com/zh/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster#1-%E6%B7%BB%E5%8A%A0-helm-chart-%E4%BB%93%E5%BA%93 "标题的直接链接")执行 helm repo add 命令，以添加包含安装 Rancher 的 Chart 的 Helm Chart 仓库。有关如何选择仓库，以及哪个仓库最适合你的用例，请参见选择 Rancher 版本。Latest：建议用于试用最新功能helm repo add rancher-latest https://releases.rancher.com/server-charts/latestStable：建议用于生产环境helm repo add rancher-stable https://releases.rancher.com/server-charts/stableAlpha：即将发布的实验性预览。helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha注意：不支持升级到 Alpha 版、从 Alpha 版升级或在 Alpha 版之间升级。2. 为 Rancher 创建命名空间[](https://ranchermanager.docs.rancher.com/zh/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster#2-%E4%B8%BA-rancher-%E5%88%9B%E5%BB%BA%E5%91%BD%E5%90%8D%E7%A9%BA%E9%97%B4 "标题的直接链接")你需要定义一个 Kubernetes 命名空间，用于安装由 Chart 创建的资源。这个命名空间的名称为 cattle-system：kubectl create namespace cattle-system3.安装rancher使用以下命令安装 Rancher：# 创建一个命名空间 kubectl create namespace cattle-system # 安装 Rancher helm install rancher rancher-stable/rancher --namespace cattle-system --set hostname=rancher.your-domain.com说明：首先创建一个名为 cattle-system 的命名空间，以便 Rancher 在这个命名空间下运行。然后，通过 Helm 安装 Rancher，hostname 是你希望将 Rancher 绑定到的域名。4.验证rancher安装可以通过以下命令检查 Rancher 的状态：# 检查 Rancher Pod 状态 kubectl -n cattle…