【Kubernetes】常用命令全解析：从入门到实战（下）

🐇明明跟你说过：个人主页

🏅个人专栏：《Kubernetes航线图：从船长到K8s掌舵者》 🏅

🔖行路有良友，便是天堂🔖

目录

一、引言

1、K8s诞生背景

2、K8s应用场景

二、调试与故障排除命令

1、查看Pod日志

2、查看集群事件

三、高级功能与实践

1、Helm介绍

2、安装Helm

3、Kustomize简介

[4、Kustomize 使用示例](#4、Kustomize 使用示例)

---

一、引言

1、K8s诞生背景

容器化技术的兴起

• 随着 Docker 的流行，容器化技术开始变得广泛应用。容器允许开发人员将应用及其依赖环境打包成一个独立的、可移植的单元，使得应用的部署和管理变得更加简便和一致。这种方式使得应用能够更高效地跨不同环境（开发、测试、生产等）运行，并且提高了应用的资源利用率。
• 然而，容器的管理和编排仍然是一个挑战，尤其是在生产环境中，单个容器无法满足应用程序的高可用性、可扩展性、负载均衡和故障恢复等需求。因此，企业开始寻找一种方式来自动化和简化容器的管理，尤其是在大规模部署时。

微服务架构的普及

• 随着应用架构从单体式应用向微服务架构的转变，开发团队需要能够高效管理大量的服务实例。微服务架构本质上要求不同的服务组件能够独立开发、独立部署、独立扩展，并且这些服务需要通过网络进行通信。
• 这种架构要求有一种统一的机制来管理多个容器、服务的发现、负载均衡、自动扩展、服务治理等问题。而 Kubernetes 提供了这些能力，成为了微服务架构的理想工具。

Google 的 Borg 系统

• Kubernetes 的诞生直接受到了 Google 内部已有的容器调度系统 Borg 的影响。Borg 是 Google 用于管理和调度容器的一个内部平台，它支持大规模容器化应用的部署、监控和管理。Borg 系统早在 2003 年就开始投入使用，Google 在使用 Borg 处理大规模容器化工作负载时积累了丰富的经验。
• 在 Borg 的基础上，Google 发现可以将其中的一些思想和技术进行开源，以便让其他公司也能使用类似的功能来管理容器化应用，尤其是支持云原生应用的管理需求。Kubernetes 就是根据 Borg 的经验而创建的。

2、K8s应用场景

1. 容器化应用的自动化部署和管理

Kubernetes 最初的目标之一就是简化容器的部署、管理和扩展。它提供了以下能力：

• **自动化容器调度：**K8s 根据资源需求和策略自动将容器分配到集群中的适当节点。
• **自愈能力：**如果某个容器出现故障，K8s 会自动重启容器，或者在其他节点上重新调度容器。
• **负载均衡：**K8s 提供了内建的负载均衡器，可以在多个容器实例之间分配流量。

**应用场景：**Kubernetes 适用于大多数容器化应用的自动化部署和管理，尤其是需要频繁发布、更新和自动恢复的场景。

2. 微服务架构

微服务架构强调将应用拆解成多个独立的、松耦合的服务，这些服务可以独立开发、部署和扩展。Kubernetes 提供了对微服务架构的完美支持：

• **服务发现：**K8s 内建的服务发现机制允许服务自动注册和发现。
• **弹性扩展：**K8s 支持根据负载自动扩展微服务实例数量，确保在高负载情况下保持系统稳定。
• **分布式管理：**K8s 使得多个微服务的部署和管理变得简单，支持跨多个节点和数据中心的分布式应用。

**应用场景：**适用于构建微服务架构的场景，特别是需要管理大量小型服务实例的系统（如电商平台、金融系统等）。

二、调试与故障排除命令

1、查看Pod日志

查看指定 Pod 的日志

使用 kubectl logs 命令查看 Pod 的日志：

kubectl logs <pod_name> -n <namespace>

• **<pod_name>：**Pod 的名称。
• **<namespace>：**Pod 所在的命名空间。如果没有指定命名空间，默认使用 default 命名空间。

例如，查看 my-pod Pod 在 default 命名空间下的日志：

kubectl logs my-pod

查看多个容器 Pod 的日志

如果 Pod 中包含多个容器，你需要指定容器名称来查看日志：

kubectl logs <pod_name> -c <container_name> -n <namespace>

例如，查看 my-pod 中名为 my-container 容器的日志：

kubectl logs my-pod -c my-container

查看最近的 Pod 日志（带时间限制）

我们可以使用 --since 参数来查看某段时间内的日志，例如最近 1 小时内的日志：

kubectl logs <pod_name> --since=1h

其他常见的时间单位有：

• **m：**分钟
• **h：**小时
• **d：**天

例如，查看过去 30 分钟内的日志：

kubectl logs my-pod --since=30m

查看 Pod 的所有历史日志

有时我们可能需要查看一个已经终止的 Pod 的日志。使用 --previous 标志来查看 Pod 上一个实例的日志：

kubectl logs <pod_name> --previous -n <namespace>

查看 Pod 日志并跟随（实时输出日志）

如果我们想实时查看 Pod 的日志输出，可以使用 -f 或 --follow 参数来跟随日志：

kubectl logs <pod_name> -f -n <namespace>

2、查看集群事件

查看集群中的所有事件

查看整个集群中的所有事件：

kubectl get events --all-namespaces

• **--all-namespaces：**显示所有命名空间中的事件。
• 如果没有加上 --all-namespaces，则只会显示当前命名空间中的事件。

查看特定命名空间中的事件

如果我们只想查看特定命名空间中的事件，可以指定 -n <namespace> 参数：

kubectl get events -n <namespace>

例如，查看 default 命名空间中的事件：

kubectl get events -n default

查看最新的事件

默认情况下，事件是按时间倒序排列的。如果我们只想查看最近的几个事件，可以使用 --sort-by 参数对事件进行排序：

kubectl get events --sort-by='.lastTimestamp'

这将按照事件的 lastTimestamp 字段对事件进行排序，从最新的事件开始显示。

查看具体资源的事件

如果我们想查看特定资源（如 Pod、Deployment、Node 等）的事件，可以指定资源的名称：

kubectl get events --field-selector involvedObject.name=<resource_name>

例如，查看 my-pod 相关的事件：

kubectl get events --field-selector involvedObject.name=my-pod

查看某个 Pod 的事件

我们可以查看与特定 Pod 相关的所有事件。例如，查看 my-pod 的事件：

kubectl describe pod my-pod -n <namespace>

在 describe 输出中，会看到该 Pod 相关的所有事件信息。

三、高级功能与实践

1、Helm介绍

Helm 是 Kubernetes 的一个包管理工具，类似于 Linux 下的 apt 或 yum，用于简化 Kubernetes 应用的部署、管理和升级。Helm 通过提供一个标准化的方式来管理 Kubernetes 应用的生命周期，使得应用部署变得更加简单和可重复。

举个例子：

• 假设我们要在 Kubernetes 上部署一个非常复杂的应用，这个应用可能涉及到多个部分，比如数据库、缓存、后台服务、前端等等。每个部分可能都需要一些配置（如端口、环境变量、存储卷等）。如果没有 Helm，我们就需要手动编写每个部分的 Kubernetes 配置文件（比如 deployment.yaml、service.yaml 等），这非常麻烦且容易出错。
• Helm 就是帮助我们把这些所有的配置文件打包成一个"模板"，我们只需要告诉 Helm 我们想安装什么应用（比如一个 Web 服务、一个数据库），它就会自动帮我们生成、配置和部署所有所需的资源，省去我们手动配置的麻烦。

主要功能：

• **快速部署应用：**通过 Helm，你可以在 Kubernetes 集群中一键安装复杂的应用。
• **管理应用版本：**Helm 会为你管理应用的版本，升级、降级、回滚都很简单。
• **共享和重用应用模板：**如果你创建了一个 Helm 包（叫做"Chart"），你可以将它分享给其他人，其他人可以使用这个模板来快速部署相同的应用。
• **自定义配置：**你可以根据需要修改 Helm 包中的配置文件，定制化应用部署。

2、安装Helm

下载 Helm 二进制文件

执行以下命令从官方 Helm 仓库下载适合操作系统的 Helm 安装包。

对于 Linux：

curl -fsSL https://get.helm.sh/helm-v3.10.2-linux-amd64.tar.gz -o helm.tar.gz

对于 macOS：

curl -fsSL https://get.helm.sh/helm-v3.10.2-darwin-amd64.tar.gz -o helm.tar.gz

**注：**v3.10.2 是 Helm 的版本号，可以根据需要修改成最新版本。

解压安装包并安装 Helm

执行以下命令解压并安装 Helm：

tar -zxvf helm.tar.gz
sudo mv linux-amd64/helm /usr/local/bin/helm

如果是 macOS，解压后移除 darwin-amd64/helm 到 /usr/local/bin/helm。

验证安装

执行以下命令，确认 Helm 已经安装成功：

helm version

如果安装成功，将看到 Helm 的版本信息。

3、Kustomize简介

Kustomize 是一个用于管理 Kubernetes 配置的工具，它通过提供一种声明式的方式，允许用户定制和修改 Kubernetes 资源配置。Kustomize 的主要优点是它不需要使用模板，而是通过简单的配置文件对 Kubernetes YAML 文件进行重用、修改和组合。

核心理念

Kustomize 的核心思想是将 Kubernetes 资源文件分离成基础配置和定制配置两部分。我们可以有一个基础的资源文件（比如部署、服务等），然后通过 Kustomize 配置文件自定义这些资源，不需要更改原始的 YAML 文件。这使得不同环境（开发、测试、生产等）之间的配置管理变得更加简单和可维护。

主要特点

1. 声明式配置： Kustomize 强调声明式的配置管理，所有的自定义修改都是通过 YAML 配置文件来声明的，而不是在代码中编写复杂的逻辑或模板。
2. 无需模板： 与 Helm 等工具不同，Kustomize 不需要模板引擎。我们只需要编辑原始的 YAML 文件或者创建新的资源层级配置文件。
3. **资源重用：**通过 Kustomize，我们可以轻松地复用基础资源文件，避免每个环境中都维护一套独立的配置。Kustomize 可以让我们对这些资源进行修改而不影响原始文件。
4. **环境管理：**Kustomize 允许我们根据不同的环境（如开发、测试、生产）提供不同的定制化设置。它通过环境层的覆盖（overlays）来实现这一点。
5. 支持多种资源类型： Kustomize 支持 Kubernetes 的各种资源类型，如 Pods、Services、Deployments、Ingress 等，且支持对它们进行添加、删除、修改等操作。
6. **原生支持 Kubernetes：**从 Kubernetes v1.14 版本开始，Kustomize 已经被原生集成到 kubectl 工具中，用户可以直接使用 kubectl 命令来调用 Kustomize 功能，而无需单独安装 Kustomize。

Kustomize 的工作原理

Kustomize 是通过在 YAML 文件中定义自定义覆盖来管理和变更 Kubernetes 资源。基本的工作流程如下：

1. 基础（Base）： 我们首先定义基础的 Kubernetes 配置资源，这些配置是固定的，通常是不会变化的，比如一个基础的 Deployment 配置。
2. 覆盖（Overlay）： 针对不同的环境（比如开发环境、生产环境等），我们可以创建覆盖配置文件。在这些覆盖文件中，我们可以修改基础资源文件中的一些配置项（如镜像版本、副本数等）。
3. 合并（Build）： Kustomize 会将基础文件和覆盖配置合并生成最终的 Kubernetes 配置文件。这是一个纯粹的 YAML 文件合并操作，完全不需要模板渲染。

4、Kustomize 使用示例

基础配置（Base）

假设我们有一个基础的 deployment.yaml 文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app-container
          image: my-app:v1

环境覆盖（Overlay）

我们可以为不同环境创建覆盖配置文件。例如，创建一个 dev 环境覆盖文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1  # dev 环境只需要一个副本
  template:
    spec:
      containers:
        - name: my-app-container
          image: my-app:v2  # dev 环境使用不同的镜像版本

kustomization.yaml

在根目录创建一个 kustomization.yaml 文件，定义基础和覆盖环境：

resources:
  - deployment.yaml   # 引用基础资源

patchesStrategicMerge:
  - dev-deployment.yaml  # 引用dev环境的覆盖配置文件

应用配置

通过 Kustomize，我们可以在命令行中生成合并后的配置，并应用到 Kubernetes 集群中：

kubectl apply -k .

这个命令会将 kustomization.yaml 中的基础和覆盖配置合并成最终的 Kubernetes 配置，并应用到集群中。

💕💕💕每一次的分享都是一次成长的旅程，感谢您的陪伴和关注。希望这些关于Kubernetes的文章能陪伴您走过技术的一段旅程，共同见证成长和进步！😺😺😺

🧨🧨🧨让我们一起在技术的海洋中探索前行，共同书写美好的未来！！！