[toc]

Kubernetes笔记1

介绍

‌Kubernetes中文官网 https://kubernetes.io/zh-cn/

Kubernetes 是什么？

本质上 ‌Kubernetes 是由 Google 开发的用于自动部署、扩缩和管理容器化应用程序的开源系统。

Kubernetes 具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建的智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。

同时，Kubernetes提供了完善的管理工具，这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。

为什么要使用 Kubernetes？

首先 Kubernetes 是一个目前主流的云原生分布式架构解决方案。这个架构基于容器技术，目的是实现容器管理的自动化，以及资源利用率的最大化。

其次，如果我们使用了 Kubernetes 作为架构设计，那么我们不必再费心于负载均衡器的选型和部署实施问题，不必再考虑引入或自己开发一个复杂的服务治理框架，不必再头疼于服务监控和故障处理模块的开发。Kubernetes 会自动处理这些任务，使我们能够更专注于业务逻辑。这样系统后期的运维难度和运维成本大幅度降低。

然后，Kubernetes是一个开放的开发平台。它不局限于任何一种语言，没有限定任何编程接口，所以不论是用Java、Go、C++还是用Python编写的服务，都可以被映射为Kubernetes的Service（服务），并通过标准的TCP通信协议进行交互。

此外，Kubernetes平台对现有的编程语言、编程框架、中间件没有任何侵入性，因此现有的系统也很容易改造升级并迁移到Kubernetes平台上。

为什么叫 Kubernetes（简称 K8s）？

Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。

背景故事

传统部署

早期，各个应用程序是直接在物理服务器上的。由于无法限制在物理服务器中运行的应用程序资源使用，因此会导致资源分配问题。

例如，如果在同一台物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，而导致其他应用程序的性能下降。一种解决方案是将每个应用程序都运行在不同的物理服务器上，但是当某个应用程序资源利用率不高时，剩余资源无法被分配给其他应用程序，而且维护许多物理服务器的成本很高。

虚拟化部署

因此，虚拟化技术被引入了。虚拟化技术允许你在单个物理服务器上运行多台虚拟机（VM）。虚拟化能使应用程序在不同虚拟机（VM）之间被彼此隔离，且能提供一定程度的安全性。因为一个应用程序的信息不能被另一应用程序随意访问。

每个虚拟机（VM）是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

虚拟化技术能够更好地利用物理服务器的资源，并且因为可轻松地添加或更新应用程序。因此可以具有更高的可扩缩性，以及降低硬件成本等等的好处。

容器部署

容器类似于虚拟机（VM），但是有着更宽松的隔离特性，使容器之间可以共享操作系统（OS）。

因此，容器比起虚拟机（VM）被认为是更轻量级的。每个容器都具有自己的文件系统、CPU、内存、进程空间等。由于容器与基础架构分离，因此可以容器可以跨平台进行移植。

容器部署相比虚拟化部署，具有以下优势：

资源利用率更高
部署更快速
管理更简单
安全性更高

为什么需要 Kubernetes？

在生产环境中，你需要管理运行着应用程序的容器，并确保服务不会下线。例如，如果一个容器发生故障，则你需要重新启动这个容器。

由于你无法时时刻刻监控容器的状态，因此如果此行为交由给系统处理，是不是会更容易一些？并且更进一步，将容器的编排，扩容，重启等一系列操作都交给系统自动处理，是不是会更方便一些？

因此 Kubernetes 诞生了。

Kubernetes 功能

Kubernetes可以提供以下功能，从而解决上述问题。

服务发现与负载均衡: Kubernetes 可以自动发现和负载均衡各个容器，确保容器在整个系统中的高可用性。
存储编排: Kubernetes 可以自动挂载你选择的存储系统，例如本地存储、公共云提供商等。
自动部署和回滚: Kubernetes 可以根据配置文件，对容器进行自动部署和回滚，确保整个系统中的高可用性。
容器自我修复: Kubernetes 可以自动重启崩溃容器、替换容器。
密钥与配置管理：Kubernetes 可以存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥等。可以在不重建容器的情况下部署和更新配置。 ............

Kubernetes（K8s）和 docker 和 Docker Compose 的区别

Docker是一个单机容器引擎。它提供了容器引擎和镜像构建工具。通过 docker 你可以将应用程序能打包成镜像、并将镜像构建为一个容器。最终让容器运行在相对隔离的环境中。

Docker Compose是单机多容器编排工具。即在Docker的基础上，将多个容器进行统一管理。

Kubernetes是分布式集群容器编排工具。通过Kubernetes 可以分布式管理大规模容器集群。

注意：Kubernetes 内置了容器进行时 containerd。因此无需Docker也能运行容器。

三者有什么关联关系？

三者不是竞争关系！而是递进 + 配合关系。

Docker 负责构建镜像（基础）。
Docker Compose 负责本地开发快速启动环境。
K8s 负责生产环境。用于分布式部署、集群管理、运维。

企业真实使用流程如下

开发本地用 Docker + Docker Compose 启动开发环境
用 Docker 把项目打包成镜像
推送到镜像仓库
在生产环境用 K8s 进行集群部署
K8s 负责运维、自愈、扩缩容

容器

镜像

镜像是一个随时可以运行的软件安装包，包含运行应用程序所需的一切：应用程序代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。

容器

容器就是镜像的实例。通过镜像，你可以创建一个容器。

容器像一个运行中的应用程序，而镜像则像一个应用程序的模板。

而一个容器包含了应用程序的所有依赖项，包括应用程序代码、容器运行时、库、配置文件等。

容器运行时 containerd

容器运行时 containerd，实际上就是负责真正 “启动、停止、管理容器” 的底层软件。

容器运行时的核心工作只有 4 件事：

拉取镜像（从镜像仓库下载）
解压镜像
创建并启动容器
管理容器生命周期（运行、停止、删除）

Kubernetes 与 Docker 与 containerd 的关系？

2013-2016：Docker 发布并成为容器生态开创者。Kubernetes 诞生，Kubernetes 初期仅支持 Docker 作为容器运行时。此时Docker = docker工具集 + containerd。 K8s = K8s工具集 + Docker。
2016-2017：K8s 推出 CRI（容器运行时接口），Docker 拆分出 containerd 。
2020-2022：K8s 宣布弃用 dockershim（Docker 适配适配器）。2022 年彻底移除，原生支持 containerd。此时 K8s = K8s工具集 + containerd。
至今：containerd 成为云原生的容器运行时标准。

总结

Docker = docker工具集 + containerd
旧Kubernetes（K8s <1.24）= K8s工具集 + Docker
新Kubernetes（K8s ≥1.24）= K8s工具集 + containerd

节点

节点通常指的就是服务器。可以是物理机或虚拟机。

K8s 只有两种节点类型

Master 节点：又称控制平面，负责管理整个k8s、调度决策和API服务。一个集群至少 1 个 Master，高可用要 3 个。
Worker 节点：又称工作平面，主要负责运行容器化应用。一个集群可以有多个 Worker 节点。每个 Worker 节点上可以运行多个 Pod，每一个pod里面可以包含多个同类型容器。

Master 节点（Master Node）

在每个Kubernetes集群里都需要有一个Master来负责整个集群的管理和控制，基本上Kubernetes的所有控制命令都发给它，它负责具体的执行过程，所有命令基本都是在Master上运行的。

Master通常会占据一个独立的服务器（高可用部署建议用3台服务器），如果它宕机或者不可用，那么对集群都将失效。

在Master上运行着以下关键组件。

组件	功能	职责
kube-apiserver	整个Kubernetes的入口组件，提供API入口。	处理所有API请求、认证授权、资源验证。为集群内组件提供服务发现机制。所有其他组件都只与它通信，不直接互访
kube-scheduler	智能调度组件	监控Pod状态，评估节点资源和负载情况，为Pod选择最佳运行节点
kube-controller-manager	控制管理组件	所有资源对象的自动化控制中心，可以将其理解为资源对象的“大总管”。
etcd	分布式键值存储	Kubernetes里的所有资源对象的数据都被保存在etcd中。

Worker 节点（Worker Node）

除了Master 节点，Kubernetes集群中的其他机器被称为Worker 节点。Worker 节点可以是一台物理主机，也可以是一台虚拟机。

Worker 节点是Kubernetes集群中的工作负载节点，每个Worker 节点都会被 Master节点分配一些工作负载（Docker容器），当某个Worker 节点宕机时，其上的工作负载会被Master节点自动转移到其他Worker 节点上。

Worker 节点负责实际运行容器（即工作负载），包含以下组件。

组件	功能	职责
kubelet	节点代理组件	负责Pod对应的容器的创建、启停等任务，同时与Master密切协作，实现集群管理的基本功能。
containerd	容器运行时	拉取镜像、创建和管理容器。提供容器运行环境
kube-proxy	网络代理组件	实现Service负载均衡，处理Pod与Service之间的通信

Pod

Pod是Kubernetes最重要的基本概念。它是 Kubernetes 中创建和管理的、最小的可部署的计算单元。

Pod 这个最小的计算单元，可以包含一个或多个容器。相当于Pod是在容器的基础上，添加了一些额外的功能，比如网络、存储等。从而让Pod中的容器能够共享资源，比如网络、存储等。。

Pod 组成结构图

由图可知，Pod 由一个Pause容器，加上一个或多个紧密相关的业务容器组成。即 pod = pause容器 + 多个业务容器

Pause容器：Pause容器是一个特殊的容器，属于Kubernetes平台的一部分。Pause容器没有运行任何应用。Pause容器的唯一作用是管理 Pod 内部的网络、存储等资源，并让业务容器共享这些资源。
业务容器：业务容器是用户定义的容器，它们是 Pod 中的主要容器，负责运行用户的应用。

为什么要有Pod?

为什么Kubernetes会设计出一个全新的Pod的概念并且Pod有这样的组成结构？

原因之一：在一组容器作为一个单元的情况下，我们难以简单地对“整体”进行判断及有效地行动。比如，一个容器死亡了，此时算是整体死亡么？是N/M的死亡率么？引入业务无关并且不易死亡的Pause容器作为Pod的根容器，以Pause容器的状态代表整组容器的状态，就简单、巧妙地解决了这个难题。
原因之二：Pod里的多个业务容器共享Pause容器的IP，共享Pause容器挂接的容器卷volume，这样既简化了密切关联的业务容器之间的通信问题，也很好地解决了它们之间的文件共享问题。

另外虽然容器与容器之间是独立的，但是有些容器在工作上是紧密相关,高耦合的。例如一个容器需要依赖另一个容器的输出。例如多个容器之间互相合作才能完成一个任务。

因此Kubernetes引入了Pod概念。通过将多个容器打包到一个Pod中，从而让这些容器可以在 Pod 内部进行共享网络，存储等资源。

因此 Pod 本质是（一个或多个容器）容器的包装器，这个包装器添加了一些额外的功能，比如网络、存储等。从而实现管理Pod，就能够同步管理Pod中的各个容器。

Pod 主要有两种用法

Kubernetes 集群中的 Pod 主要有两种用法

单容器 Pod：每个 Pod 只包含一个容器。这是最常见的用法。这种情况下可以将 Pod 看作单个容器的包装器，并且相当于 Kubernetes 直接管理 Pod，而不是容器。
多容器 Pod：每个 Pod 包含多个容器。只有在一些场景中，多个容器之间紧密关联时你才应该使用这种模式。例如将多个紧密相关，高耦合的容器打包到一个Pod中。从而让这些容器在 Pod 内部进行共享资源。这种情况下，就可以通过扩容Pod来实现多个容器的同步扩容。

Label（标签）

在Kubernetes（k8s）中，标签（Labels）是一种非常重要的概念。Label是Kubernetes中用于标识和选择资源的键值对。

Label可以被附加到各种资源对象上，例如Node、Pod、Service等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上。Label通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。

我们可以通过给指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作。

Label 相当于我们熟悉的“标签”。给某个资源对象定义一个Label，就相当于给它打了一个标签，随后可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，Kubernetes通过这种方式实现了类似SQL的简单又通用的查询机制。

Label的组成

键值对：每个Label标签由一个键和一个值组成，键和值都是字符串。

Label 的作用

资源标识：为资源添加标识信息
资源选择：通过Label Selector选择具有特定Label的资源
资源组织：将相关资源组织在一起

Label 的使用场景

Service选择Pod：Service通过Label选择器找到对应的Pod
Deployment管理Pod：Deployment通过Label管理Pod的副本
资源分组：将相关资源打上相同的Label，方便后续的资源选择和管理。

Label Selector（标签选择器）

标签选择器用于筛选匹配特定标签的资源。

Label Selector的使用场景如下。

kube-controller进程通过Label Selector来筛选要监控的Pod副本数量，使Pod副本数量始终符合预期设定的全自动控制流程。
kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制。
通过对某些Node定义特定的Label，并且在Pod定义文件中使用NodeSelector这种标签调度策略，kube-scheduler进程可以实现Pod定向调度的特性。

Annotation（注解）

Annotation是Kubernetes中用于存储任意非标识性数据的键值对，与Label类似但不用于选择资源。

通常是用户任意定义的附加信息，以便于外部工具查找。在很多时候，Kubernetes的模块自身会通过Annotation标记资源对象的一些特殊信息。

常用Annotation来记录的信息如下

存储元数据：存储资源的描述信息。build信息、release信息、Docker镜像信息等，例如时间戳、release id号、PR号、镜像Hash值、Docker Registry地址等。
工具集成：为第三方工具提供配置信息。程序调试工具信息，例如工具名称、版本号等。
调试信息：存储调试和监控相关的信息。日志库、监控库、分析库等资源库的地址信息。

Label 与 Annotation 的区别

特性	Label	Annotation
用途	标识和选择资源	存储元数据
选择器	可以被Selector选择	不能被Selector选择
数据量	较小，用于标识	可以较大，用于存储任意数据
查询效率	高，支持索引	低，不支持索引

Controller 控制器（管理Pod）

K8s 所有资源（Pod、Service、ConfigMap…）都是通过各种控制器来管理的。不同的控制器管理不同的资源对象。

为了满足不同的业务场景, Kubemetes 提供了多种 Controller 控制器, 包括 Deployment, Replicaset、 DaemonSet、StatefuleSet、Job等

控制器的大致作用

管理资源对象的生命周期（创建、销毁、重启、迁移）
实现资源对象的扩缩容、滚动更新、回滚
维持整个集群最终一致性

没有控制器，K8s 就只是一堆孤立资源，毫无编排能力。

Replicaset 控制器（RS，Pod副本集控制器）

Replicaset 控制器负责监控和维护集群中 Pod 的副本(replicas)数，确保Pod的副本数是设置的期望数量, 如果副本数不是期望数量, 则 Replicaset 控制器会自动管理Pod的生命周期，确保副本数符合期望数量。

Deployment 控制器（最常用）

Deployment是最常用的用于管理Pod的控制器。可以管理 Pod 的创建、更新、销毁。并确保 Pod 按照期望的状态运行。

Deployment 控制器底层是 ReplicaSet 控制器。是在 ReplicaSet 之上再封装一层形成的。

因此底层逻辑：Deployment → 管理 ReplicaSet → 管理 Pod

Deployment的典型使用场景有以下几个。

创建一个Deployment对象来生成对应的Replicaset并完成Pod副本的创建。
检查Deployment的状态来看部署动作是否完成（Pod副本数量是否达到预期的值）。
更新Deployment以创建新的Pod（比如镜像升级）。
如果当前Deployment不稳定，则回滚到一个早先的Deployment版本。
扩展Deployment以应对高负载。
查看Deployment的状态，以此作为发布是否成功的指标。

命令示例

# 例如可以通过YAML文件创建Deployment对象，然后生成对应的Replicaset并完成Pod副本的创建
kubectl create -f app-deployment.yaml

# 检查Deployment的状态
kubectl get deployments

# 检查 Replicaset 的状态
kubectl get replicasets

# 检查 Pod 的状态
kubectl get pods

Job 控制器（用于管理一次性Pod）

Job 控制器是一种用于管理一次性Pod的控制器。用于运行结束就删除的Pod。而其他的Controller控制器中的Pod通常是需要长期运行的。

Job控制器与其他控制器的区别

Job所控制的Pod是短暂运行的，其中的每个容器都仅仅运行一次。当Job控制的所有Pod副本都运行结束时，对应的Job也就结束了。
Job在实现方式上与其他控制器不同，Job生成的Pod副本是不能自动重启的。因此，当对应的Pod副本都执行完成时，相应的Job控制器也就完成了控制使命。

CronJob 控制器（用于管理定时任务）

CronJob 控制器是一种用于管理定时任务的控制器。用于运行定时任务的Pod。

CronJob 控制器的典型使用场景有以下几个。

（1）定时备份数据。
（2）定时删除过期数据。
（3）定时发送邮件通知。
（4）定时执行数据库维护。

yaml

# 定时任务的YAML文件示例
apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-cronjob
spec:
  schedule: "0 0 * * *"
  jobTemplate:
    spec:
      template:
        metadata:
          labels:
            app: backup
        spec:
          containers:
          - name: backup-container
            image: backup-image:1.0
            command: ["/backup.sh"]
            args: ["-d", "7"]

上面这个文件示例，创建了一个CronJob对象，这个CronJob对象会每天凌晨0点执行一次备份任务。备份任务的容器镜像为backup-image:1.0，备份任务的命令为"/backup.sh"，备份任务的参数为"-d 7"。

DaemonSet 控制器（控制每个Node节点上的Pod数量）

DaemonSet 控制器可以确保每个Node节点上都最多运行一个 Pod 副本实例。

StatefuleSet 控制器（管理有状态服务的Pod）

在Kubernetes系统中，Replicaset、Deployment、DaemonSet和Job等控制器都面向无状态的服务。但现实中有很多服务是有状态的。例如MySQL集群、MongoDB集群、kafka集群、ZooKeeper集群等。

有状态服务的集群的共同点：

（1）集群中的每个节点都有固定的身份ID，通过这个ID，集群中的成员可以相互发现并通信。
（2）集群的规模是比较固定的，集群规模不能随意变动。
（3）集群中的每个节点都是有状态的，通常会持久化数据到永久存储中。
（4）如果磁盘损坏，则集群里的某个节点无法正常运行，集群功能受损。

又因为通常情况下，扩容产生的pod的名称是随机的，IP地址也是随机的，所以普通的控制器无法针对有状态服务的Pod资源进行管理。

为了解决这个问题，Kubernetes 新增了StatefulSet 控制器。StatefulSet从本质上来说，可以看作Deployment 控制器的一个特殊变种，它有如下特性。

StatefulSet 控制器的特性

（1）StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。假设StatefulSet的名称为kafka，那么第1个Pod叫kafka-0，第2个叫kafka-1，以此类推。
（2）StatefulSet控制的Pod副本的启停顺序是受控的。即操作第n个Pod时，前n-1个Pod已经是运行且准备好的状态。
（3）StatefulSet里的Pod采用稳定的持久化存储卷。删除Pod时默认不会删除与之相关的存储卷（为了保证数据的安全）。

Service（给Pod提供固定访问入口）

Service服务也是Kubernetes里的核心资源对象之一。

Kubernetes里的每个Service其实相当于微服务架构中的一个微服务。

Service 用于将一组（一个或多个）Pod暴露到外部的工具。它给一组Pod提供固定访问入口，并自动负载均衡到这些Pod上。

Service的作用示意图

如图所示，Kubernetes中的Service定义了一个服务的访问入口地址。Service与后端Pod副本集群之间则是通过Label Selector 标签选择器来进行关联。因此前端的应用（Pod）通过服务的访问入口地址从而能够访问到后端的Pod集群实例。

为什么需要通过Service来访问Pod？

在Kubernetes中，Pod 会频繁地销毁和重启，它们的 IP 会不断发生变化，因此用 IP 来访问Pod不太现实。

为此，Kubernetes 提供了 Service 来定义了外界访问 Pod 的方式。Service 有自己的 IP 和端口，Service 为 Pod集群提供了负载均衡。

Service 的YAML文件

下面是一个yaml文件示例。用于创建一个service资源对象。

yaml

apiVersion: v1
kind: Service
metadata:
  name: tomcat-service
spec:
  selector:
    app: tomcat-app  # 标签为 app=tomcat-app 的 Pod
  ports:
  - port: 8080   
    targetPort: 8080

上述内容定义了一个名为tomcat-service的Service，它的服务端口为8080，拥有“app=tomcat-app”这个Label的所有Pod实例都属于这个名为tomcat-service的Service。

# 通过yaml文件创建该service
kubectl create -f xxx.yaml

Volume（存储卷）

Volume（存储卷）是指Pod中能够被多个容器访问的共享目录。它解决了Pod中容器数据持久化的问题。

Volume的使用也比较简单，在大多数情况下，我们需要先在Pod上声明一个Volume，然后在容器里引用该Volume并挂载（Mount）到容器里的某个目录上即可。

Kubernetes的Volume概念、用途和目的与Docker的Volume比较类似，但两者不能等价。

Kubernetes的Volume和Docker的Volume的区别

首先，Kubernetes中的Volume被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下；
其次，Kubernetes中的Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，Volume中的数据也不会丢失。
最后，Kubernetes支持多种类型的Volume，例如GlusterFS、Ceph等先进的分布式文件系统。

为什么需要Volume？

容器临时性：容器重启后数据会丢失
Pod临时性：Pod销毁后数据会丢失
数据共享：同一Pod中的多个容器需要共享数据

Volume的类型

Kubernetes提供了非常丰富的Volume类型，下面逐一进行说明。

常见的Volume类型

emptyDir：临时存储，Pod删除后数据会丢失
hostPath：将宿主机的目录挂载到Pod中
PersistentVolumeClaim (PVC)：持久化存储，通过PVC申请存储资源
ConfigMap：将ConfigMap作为存储卷挂载
Secret：将Secret作为存储卷挂载

emptyDir Volume

emptyDir Volume是在Pod分配到Node时创建的。也是 Kubernetes自动分配的一个目录，并且无须指定宿主机上对应的目录文件。

作用如下：

临时目录，用于存储容器运行时产生的临时数据。
当Pod被删除时，该目录会被自动删除。
该目录只能被一个容器挂载。

hostPath Volume

hostPath Volume 是指在Pod上挂载宿主机上的文件或目录。

作用如下：

用于在Pod上挂载宿主机上的文件或目录。
用于将宿主机上的数据和Pod中的数据进行双向同步。

Namespace （命名空间）

Namespace（命名空间）是Kubernetes系统中的另一个非常重要的概念。

在Kubernetes中，Namespace 是用于隔离和组织资源的逻辑分组。通过将集群内部的资源对象“分配”到不同的Namespace中，形成逻辑上分组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。

每个 Namespace 都有自己的 IP 地址范围，也可以包含多个 Pod、Service、ConfigMap 等资源。

通过Namespace 也可以划分出开发 / 测试 / 生产环境

Namespace 的作用

资源隔离：不同Namespace之间的资源相互隔离，避免冲突
访问控制：可以为不同的Namespace设置不同的权限
环境分离：将开发、测试、生产环境的资源分开管理
资源配额：可以为Namespace设置资源使用限制

常见的 Namespace

default：默认的Namespace，未指定Namespace的资源会创建在这里
kube-system：Kubernetes系统组件所在的Namespace
kube-public：公共资源Namespace，所有用户都可以访问
kube-node-lease：用于节点租期的Namespace

Namespace 的使用

如下所示的YAML定义了名为development的Namespace。

yaml

apiVersion: v1
kind: Namespace
metadata:
  name: development

操作Namespace的命令示例：

bash

# 查看所有Namespace
kubectl get namespaces

# 创建Namespace
kubectl create namespace my-app

# 在指定Namespace中创建资源
kubectl apply -f deployment.yaml -n my-app

# 查看指定Namespace中的资源
kubectl get pods -n my-app

ConfigMap

在Kubernetes中，ConfigMap 是用于存储和管理配置文件。从而将配置和应用分离。

为什么需要 ConfigMap ？

Docker 如何管理配置的。

方式1：通过容器的环境变量来管理配置。
方式2：通过Docker Volume将容器外的配置文件映射到容器内。

这两种方式对于各个集群容器来说，需要管理一大堆分散的配置文件，这会导致配置管理的复杂度增加。

在大多数情况下，我们都希望能集中管理系统的配置参数，而不是管理一堆配置文件。因此 kubernetes 提供了 ConfigMap 集中管理配置参数。

ConfigMap 的实现方式

首先，把所有的配置项都当作key-value字符串，然后把它们存储到ConfigMap中。

接下来，Kubernetes提供了一种机制，将存储在ConfigMap中的数据通过Volume映射的方式变成目标Pod内的配置文件，不管目标Pod被调度到哪台服务器上，都会完成自动映射。

进一步地，如果ConfigMap中的key-value数据被修改，则映射到Pod中的“配置文件”也会随之自动更新。

于是 ConfigMap 就成了分布式系统中最为简单（使用方法简单，但背后实现比较复杂）且对应用无侵入的配置中心。

类似如图所示

ConfigMap

ConfigMap 用于存储非敏感的配置数据，如配置文件、命令行参数、环境变量等。

ConfigMap 的使用方式

环境变量：将ConfigMap中的数据作为环境变量注入到Pod中
命令行参数：在容器启动命令中引用ConfigMap的值
配置文件：将ConfigMap挂载为配置文件

yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database.url: "mysql://localhost:3306"
  cache.size: "100"

Secret

Secret 用于存储敏感信息，如密码、OAuth令牌、SSH密钥等。Secret中的数据会进行Base64编码。

Secret 的类型

Opaque：通用的Secret类型，用于存储任意数据
kubernetes.io/dockerconfigjson：用于存储Docker镜像仓库的认证信息
kubernetes.io/tls：用于存储TLS证书
kubernetes.io/service-account-token：用于存储ServiceAccount的令牌

yaml

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: YWRtaW4=  # base64编码的 "admin"
  password: cGFzc3dvcmQ=  # base64编码的 "password"

ConfigMap 与 Secret 的区别

特性	ConfigMap	Secret
数据类型	非敏感数据	敏感数据
数据编码	明文存储	Base64编码
使用场景	配置文件、环境变量	密码、证书、密钥
安全性	较低	较高（支持加密）

Ingress (网关路由)

Ingress 在整个 Kubernetes 架构中起着网关路由的作用。它可以将外部的请求分发到Kubernetes集群中的某个Service 上。

Ingress 起到了统一入口、路由、证书的作用。

Ingress 与 Service 的区别

Service：工作在4层（TCP/UDP），基于IP和端口进行负载均衡
Ingress：工作在7层（HTTP/HTTPS），基于域名和路径进行路由

Ingress 的核心功能

域名路由：根据不同的域名将请求路由到不同的Service
路径路由：根据URL路径将请求路由到不同的Service
SSL/TLS终止：处理HTTPS证书，减轻后端Pod的压力
负载均衡：在多个Service实例之间分发流量

常见的 Ingress 控制器

Nginx Ingress Controller：最流行的Ingress控制器
Traefik：现代化的反向代理和负载均衡器
HAProxy：高性能的负载均衡器
Istio Gateway：服务网格中的网关

Kubernetes笔记1 ​

介绍 ​

Kubernetes 是什么？ ​

为什么要使用 Kubernetes？ ​

为什么叫 Kubernetes（简称 K8s）？ ​

背景故事 ​

Kubernetes（K8s）和 docker 和 Docker Compose 的区别 ​

容器 ​

镜像 ​

容器 ​

容器运行时 containerd ​

Kubernetes 与 Docker 与 containerd 的关系？ ​

节点 ​

Master 节点（Master Node） ​

Worker 节点（Worker Node） ​

Pod ​

为什么要有Pod? ​

Pod 主要有两种用法 ​

Label（标签） ​

Label Selector（标签选择器） ​

Annotation（注解） ​

Controller 控制器（管理Pod） ​

Replicaset 控制器（RS，Pod副本集控制器） ​

Deployment 控制器 （最常用） ​

Job 控制器（用于管理一次性Pod） ​

CronJob 控制器（用于管理定时任务） ​

DaemonSet 控制器（控制每个Node节点上的Pod数量） ​

StatefuleSet 控制器（管理有状态服务的Pod） ​

Service（给Pod提供固定访问入口） ​

Service的作用示意图 ​

为什么需要通过Service来访问Pod？ ​

Service 的YAML文件 ​

Volume（存储卷） ​

Volume的类型 ​

Namespace （命名空间） ​

ConfigMap ​

ConfigMap ​

Secret ​

Ingress (网关路由) ​

Kubernetes笔记1

介绍

Kubernetes 是什么？

为什么要使用 Kubernetes？

为什么叫 Kubernetes（简称 K8s）？

背景故事

Kubernetes（K8s）和 docker 和 Docker Compose 的区别

容器

镜像

容器

容器运行时 containerd

Kubernetes 与 Docker 与 containerd 的关系？

节点

Master 节点（Master Node）

Worker 节点（Worker Node）

Pod

为什么要有Pod?

Pod 主要有两种用法

Label（标签）

Label Selector（标签选择器）

Annotation（注解）

Controller 控制器（管理Pod）

Replicaset 控制器（RS，Pod副本集控制器）

Deployment 控制器（最常用）

Job 控制器（用于管理一次性Pod）

CronJob 控制器（用于管理定时任务）

DaemonSet 控制器（控制每个Node节点上的Pod数量）

StatefuleSet 控制器（管理有状态服务的Pod）

Service（给Pod提供固定访问入口）

Service的作用示意图

为什么需要通过Service来访问Pod？

Service 的YAML文件

Volume（存储卷）

Volume的类型

Namespace （命名空间）

ConfigMap

ConfigMap

Secret

Ingress (网关路由)