叩丁狼K8s - 概念篇

叩丁狼k8s - 概念

我的docker笔记
叩丁狼docker视频

一：K8s基础概念

为啥要使用容器化部署

k8s的特点和优势

• 容器化部署
• 自我修复
• 弹性伸缩
• 自动部署和回滚
• 服务发现和负载均衡
• 机密和配置管理
• 存储编排
• 批处理

k8s和其他企业级容器调度平台的对比

• Apache Mesos
  • Mesos 是一个分布式调度系统内核，早于 Docker 产生，Mesos 作为资源管理器，从 DC/OS (数据中心操作系统)的角度提供资源视图。主/从结构工作模式，主节点分配任务，并用从节点上的 Executor 负责执行，通过 Zookeeper 给主节点提供服务注册、服务发现功能。通过 Framework Marathon 提供容器调度的能力。
  • 支持超大型规模的节点管理，模拟测试支持超过 5w+ 节点，在大规模上拥有较大优势。
• Docker swarm
  • Docker Swarm 是一个由 Docker 开发的调度框架。由 Docker 自身开发的好处之一就是标准 Docker API 的使用，Swarm 由多个代理（Agent）组成，把这些代理称之为节点（Node）。这些节点就是主机，这些主机在启动 Docker Daemon 的时候就会打开相应的端口，以此支持 Docker 远程 API。这些机器会根据 Swarm 调度器分配给它们的任务，拉取和运行不同的镜像。
  • 入门门槛、学习成本较低，使用更便捷，适用于中小型系统。
• Google Kubernetes
  • Kubernetes 是基于 Google 在过去十五年来大量生产环境中运行工作负载的经验。Kubernetes 的实现参考了 Google 内部的资源调度框架，但并不是 Borg 的内部容器编排系统的开源，而是借鉴 Google 从运行 Borg 获得的经验教训，形成了 Kubernetes 项目。
  • 它使用 Label 和 Pod 的概念来将容器划分为逻辑单元。Pods 是同地协作（co-located）容器的集合，这些容器被共同部署和调度，形成了一个服务，这是 Kubernetes 和其他两个框架的主要区别。相比于基于相似度的容器调度方式（就像 Swarm 和Mesos），这个方法简化了对集群的管理。
  • 最流行等容器编排解决方案框架，基于 Google 庞大的生态圈及社区产生的产品。通过 Pods 这一抽象的概念，解决 Container 之间的依赖于通信问题。Pods，Services，Deployments 是独立部署的部分，可以通过 Selector 提供更多的灵活性。内置服务注册表和负载平衡。
  • 适用度更广，功能更强大，相较于 Mesos 来说节点规模较小，

1：K8s组件构成

K8s架构分成master(控制面板)和node(节点)

🚀 核心要记住的是通过kubectl的命令调用master的api-server, api-server解析命令之后，调用自己或者调用node的pod容器组，完成命令到服务的访问。

核心架构图如下，标记为绿色部分的为重要的三个内容，各自框中的组件为要安装的内容

外部调用方式

• kubectl：命令行工具
• Dashboard：可视化界面的UI

控制面板master

• api-server：接口服务，基于REST风格开放K8s的服务
• cloud-controller-manager：云控制器管理器，第三方云平台提供的控制器API对接管理功能
• kube-controller-manager：控制器管理器，管理各个类型的控制器，针对k8s的各种资源进行管理
• kube-scheduler：调度器，负责将pod基于一定的算法，将其调用到更加合适的节点上
• etcd：k8s的数据库，分布式的键值类型的数据库，基于Raft算法实现自主的集群高可用

工作节点node

• kubelet：负责pod的生命周期，存储和网络
• kube-proxy：网络代理，负责service的服务发现和负载均衡(4层)
• container-runtime：容器运行时的环境，docker, containerd, CRI-D
• pod ：容器组，一个pod中能有1个或者多个容器，同一个容器组中的容器共享存储和网络。pod是环境隔离的最小单位

附加组件 - 了解即可

• kube-dns：负责整个集群提供dns服务
• ingress-controller：service只是负责节点内部的网络通信，ingress是负责外部通信的，为服务提供外网接口
• prometues：监控平台，一般配合grafana，可视化监控
• Federation：提供跨可用区的集群
• fluentd-elasticsearch：提供集群的日志收集，存储和查询

2：K8s分层架构

• 你用接口层（kubectl/API）发出指令。
• 管理层（控制器/Scheduler）理解你的指令，并制定计划使其实现。
• 应用层（Deployment/Service/Pod）是你指令的具体内容，即你要运行什么应用以及如何访问它。
• 核心层（API Server/etcd/Kubelet）则负责执行管理层的计划，在底层基础设施上真正地把应用跑起来。

接口层

这一层是用户与Kubernetes集群交互的入口和方式，提供了各种工具和标准来使用和管理集群。

• 职责：提供人机与机机交互的接口。
• 关键组件/技术：
  • 命令行工具 (kubectl): 最常用的命令行工具，允许用户通过命令创建、管理和删除资源。
  • API: 最核心的接口。所有通过kubectl或UI执行的操作，最终都会转换为对Kubernetes API的RESTful调用。这是所有自动化工具和平台集成的基础。
  • Dashboard (UI): 官方的Web图形化界面，提供了一种可视化的方式来管理集群。
  • 客户端库 (Client Libraries): 如client-go等，允许开发者用Go、Python等语言编写程序来直接与API Server交互。
• 这是用户和外部系统操作K8s的“操作台”和“插座”。

管理层

这一层是Kubernetes的“大脑”，负责确保系统的实际状态始终与用户声明的期望状态保持一致。

• 职责：通过控制循环实现部署、扩缩容、更新、修复等自动化管理功能。
• 关键概念/组件：
  • 控制器 (Controller): 集群中的自动化管家。它们持续地监控集群状态（通过API Server），一旦发现实际状态与期望状态不符，就采取措施驱动实际状态向期望状态收敛。
  • 调度器 (Scheduler): 一个特殊的控制器，负责根据资源需求、策略、约束等条件，决定Pod应该在哪个节点上运行。
  • 云控制器管理器 (Cloud Controller Manager): 用于与底层云提供商（如AWS、Azure、GCP）的API交互，管理节点、负载均衡器、存储卷等云资源。
• 这是集群的“自动驾驶系统”，自动执行运维任务，保证应用高可用。

应用层

这一层是开发者最关心的部分，定义了应用的封装、组成和访问方式。其实就是如何操作pod的

• 职责：提供各种资源对象来部署和暴露应用程序。
• 关键概念/组件：
  • 工作负载资源 (Workload Resources): 如 Pod、Deployment、StatefulSet、DaemonSet、Job。它们定义了应用程序的运行方式（如多少个副本、如何更新）。
  • 服务与网络 (Service & Networking): 如 Service（提供稳定的网络访问和负载均衡）、Ingress（管理外部访问的HTTP路由）。它们定义了应用如何被网络访问。
  • 配置与存储 (Configuration & Storage): 如 ConfigMap、Secret、PersistentVolume。它们将配置、敏感数据和存储与应用解耦。
• 这是开发者定义和组装应用程序的“积木盒”和“蓝图”。

核心层

这一层是Kubernetes的“基石”和“引擎”，提供了最基础、最核心的功能。

• 职责：提供集群最底层的核心功能，包括资源调度、服务发现、API处理和数据持久化。
• 关键组件：
  • API Server: 所有集群操作的唯一入口，是管理层、接口层与其它组件通信的枢纽。
  • Etcd: 分布式键值存储数据库，持久化存储整个集群的所有配置和数据状态，是集群的“唯一信源”。
  • 容器运行时 (Container Runtime): 如 containerd、CRI-O，负责真正从镜像运行容器、管理容器的生命周期。
  • Kubelet: 运行在每个节点上的代理，负责确保容器在Pod中健康运行。
  • Kube-Proxy: 运行在每个节点上，维护网络规则，实现Service的网络转发。
• 一句话总结：这是驱动整个集群运行的“发动机”和“底盘”，提供了最基础的计算、网络、存储和协调能力。

3：服务的分类

K8s中的服务分成两类，分别是无状态服务和有状态服务

3.1：无状态服务

不会对本地环境产生任何的依赖，不会存储数据到本地的磁盘

• 优点：对客户端透明，无依赖关系，可以高效实现扩容、迁移
• 缺点：不能存储数据，需要额外的数据服务支撑
• 代表是：nginx，apache

3.2：有状态服务

会对本地环境有所依赖，例如会存储数据到本地的磁盘

• 优点：可以独立存储数据，实现数据管理
• 缺点：集群环境下需要实现主从、数据同步、备份、水平扩容复杂
• 代表是：mysql，redis

二：资源和对象概念(重中之重)

类别于java，资源是类，对象是类的实例

资源清单中可以定义所有的资源的对象，其中规定的就是对象的规约spec, 也就是用户希望对象是怎么运行的

Kubernetes 中的所有内容都被抽象为“资源”，如 Pod、Service、Node 等都是资源。

“对象"就是“资源”的实例，是持久化的实体。如某个具体的 Pdg、某个具体的 Node。

Kubernetes 使用这些实体去表示整个集群的状态。对象的创建、删除、修改都是通过 “Kubernetes API”，也就是“Api Server" 组件提供的 API接口，这些是 RESTful 风格的 Api，与k8s 的“万物皆对象"理念相符。

命令行工具 “kubectl”，实际上也是调用 kubernetes apl。

K8s 中的资源类别有很多种，kubectl 可以通过配置文件来创建这些“对象”，配置文件更像是描述对象“属性"的文件，配置文件格式可以是 JSON或YAML，常用YAML。

1：资源的分类

资源分为元数据，集群和命名空间

1.1：元数据

描述当Pod发生了什么事情，去做什么事

• 创建pod -> pod template
• 扩缩容pod -> HPA
• 限制pod -> limitRange

HPA(扩缩容的时候会用到)

Pod 自动扩容：可以根据 CPU 使用率或自定义指标（metrics）自动对 Pod 进行扩/缩容。

• 控制管理器每隔30s（可以通过–horizontal-pod-autoscaler-sync-period修改）查询metrics的资源使用情况
• 支持三种metrics类型
  • 预定义metrics（比如Pod的CPU）以利用率的方式计算
  • 自定义的Pod metrics，以原始值（raw value）的方式计算
  • 自定义的object metrics
• 支持两种metrics查询方式：Heapster和自定义的REST API
• 支持多metrics

Pod template

Pod Template 是关于 Pod 的定义，但是被包含在其他的 Kubernetes 对象中（例如 Deployment、StatefulSet、DaemonSet 等控制器）。控制器通过 Pod Template 信息来创建 Pod。

LimitRange

可以对集群内 Request 和 Limits 的配置做一个全局的统一的限制

相当于批量设置了某一个范围内（某个命名空间）的 Pod 的资源使用限制。

1.2：集群

Namespace命名空间

Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群，这些虚拟集群被称为命名空间。

作用是用于实现多团队/环境的资源隔离。

命名空间 namespace 是 k8s 集群级别的资源，可以给不同的用户、租户、环境或项目创建对应的命名空间。

默认 namespace：

• kube-system 主要用于运行系统级资源，存放 k8s 自身的组件
• kube-public 此命名空间是自动创建的，并且可供所有用户（包括未经过身份验证的用户）读取。此命名空间主要用于集群使用，关联的一些资源在集群中是可见的并且可以公开读取。此命名空间的公共方面知识一个约定，但不是非要这么要求。
• default 你在创建pod 时如果没有指定 namespace，则会默认使用 default

Node节点

不像其他的资源（如 Pod 和 Namespace），Node 本质上不是Kubernetes 来创建的，Kubernetes 只是管理 Node 上的资源。

虽然可以通过 Manifest 创建一个Node对象，但 Kubernetes 也只是去检查是否真的是有这么一个 Node，如果检查失败，也不会往上调度 Pod。

clusterRole集群角色

ClusterRole 是一组权限的集合，但与 Role 不同的是

ClusterRole 可以在包括所有 Namespace 和集群级别的资源或非资源类型进行鉴权。

clusterRoleBinding

ClusterRoleBinding：将 Subject 绑定到 ClusterRole，ClusterRoleBinding 将使规则在所有命名空间中生效。

1.3：命名空间级资源

1.3.1：工作负载型(重中之重)

1.3.1.1：pod(容器组)

Pod（容器组）是 Kubernetes 中最小的可部署单元。

一个 Pod（容器组）包含了一个应用程序容器（某些情况下是多个容器）、存储资源、一个唯一的网络 IP 地址、以及一些确定容器该如何运行的选项。

Pod 容器组代表了 Kubernetes 中一个独立的应用程序运行实例，该实例可能由单个容器或者几个紧耦合在一起的容器组成。

Docker 是 Kubernetes Pod 中使用最广泛的容器引擎；Kubernetes Pod 同时也支持其他类型的容器引擎。

Kubernetes 集群中的 Pod 存在如下两种使用途径：

• 一个 Pod 中只运行一个容器。“one-container-per-pod” 是 Kubernetes 中最常见的使用方式。此时，您可以认为 Pod 容器组是该容器的装饰器(wrapper)，Kubernetes 通过 Pod 管理容器，而不是直接管理容器。
• 一个 Pod 中运行多个需要互相协作的容器。您可以将多个紧密耦合、共享资源且始终在一起运行的容器编排在同一个 Pod 中，这样这些容器可以网络互通，文件系统共享

Pod中增加了一个pause的概念，实现了文件系统和网络的互通共享。

1.3.1.2：replicas(副本)

一个 Pod 可以被复制成多份，每一份可被称之为一个“副本(replicas)”

这些“副本”除了一些描述性的信息（Pod 的名字、uid 等）不一样以外，其它信息都是一样的

譬如 Pod 内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的，这些副本提供同样的功能。

Pod 的控制器通常包含一个名为 “replicas” 的属性。“replicas”属性则指定了特定 Pod 的副本的数量

当当前集群中该 Pod 的数量与该属性指定的值不一致时，k8s 会采取一些策略去使得当前状态满足配置的要求

可以借助deployment无状态控制器和statefulSet有状态控制器的配置完成自动扩缩容

也可以使用kubectl scale手动扩缩容(这个命令不能直接作用于pod，也是作用于控制器)

1.3.1.3：controller(控制器)

当 Pod 被创建出来，Pod 会被调度到集群中的节点上运行，Pod 会在该节点上一直保持运行状态，直到进程终止、Pod 对象被删除、Pod 因节点资源不足而被驱逐或者节点失效为止。

Pod 并不会自愈，当节点失效，或者调度 Pod 的这一操作失败了，Pod 就该被删除。

如此，单单用 Pod 来部署应用，是不稳定不安全的。

Kubernetes 使用更高级的资源对象控制器来实现对Pod的管理。控制器可以为您创建和管理多个 Pod，管理副本和上线，并在集群范围内提供自修复能力。

例如，如果一个节点失败，控制器可以在不同的节点上调度一样的替身来自动替换 Pod。

RC，RS，Deployment

这三者都是适用于部署无状态服务(nginx，Apache…)的控制器

🚀 Replication Controller - 被舍弃

Replication Controller 简称 RC，RC 是 Kubernetes 系统中的核心概念之一

简单来说，RC 可以保证在任意时间运行 Pod 的副本数量，能够保证 Pod 总是可用的

如果实际 Pod 数量比指定的多那就结束掉多余的，如果实际数量比指定的少就新启动一些Pod

当 Pod 失败、被删除或者挂掉后，RC 都会去自动创建新的 Pod 来保证副本数量，所以即使只有一个 Pod，我们也应该使用 RC 来管理我们的 Pod。

可以说，通过 ReplicationController，Kubernetes 实现了 Pod 的高可用性。

🚀 Replication Set -> RC在v1.11被废弃，被这个RS代替了

RS 跟 RC 没有本质的不同，只是名字不一样，并且 RS 支持集合式的 selector

RS在RC的基础上为了更好的和pod进行绑定，引入了Label和selector两个概念

• label （标签）是附加到 Kubernetes 对象（比如 Pods）上的键值对，用于区分对象（比如Pod、Service）。
  • label 旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。
  • label 可以用于组织和选择对象的子集。
  • label 可以在创建时附加到对象，随后可以随时添加和修改。
  • 可以像 namespace 一样，使用 label 来获取某类对象
• label 可以与 selector 一起配合使用，用表达式对条件加以限制，实现更精确、更灵活的资源查找。
  • label 与 selector 配合，可以实现对象的“关联”
  • “Pod 控制器” 与 Pod 是相关联的 —— “Pod 控制器”依赖于 Pod
  • 可以给 Pod 设置 label，然后给“控制器”设置对应的 selector，这就实现了对象的关联。

🚀 deployment -> Deployment 为 Pod 和 Replica Set 提供声明式更新。

你只需要在 Deployment 中描述你想要的目标状态是什么，Deployment controller 就会帮你将 Pod 和 Replica Set 的实际状态改变到你的目标状态。

你可以定义一个全新的 Deployment，也可以创建一个新的替换旧的 Deployment。

在业务中一般不会直接创建RC/RS，而是通过创建deployment得方式创建RC/RS

deployment提供了更复杂的一些部署相关的功能：

• 创建 Replica Set / Pod
• 滚动升级/回滚(RS1旧版本 -> RS2新版本的自动滚动升级，全程不停机，用户无感知，还可以RS2 -> RS1回退)
• 平滑扩容和缩容(RS1中原本只有2个副本，现在变成3个，这个扩容的过程是平滑的)
• 暂停与恢复 Deployment

StatefulSet

🚀 用户部署有状态服务的对象(mysql, redis…)

🚀 有状态的服务有如下特点

• 稳定的持久化存储：即 Pod 重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现
• 稳定的网络标志：即 Pod 重新调度后其 PodName 和 HostName 不变，基于 Headless Service（即没有 Cluster IP 的 Service）来实现
• 有序部署&有序扩展：即 Pod 是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从 0到 N-1，在下一个Pod 运行之前所有之前的 Pod 必须都是 Running 和 Ready 状态），基于 init containers 来实现
• 有序收缩，有序删除：有序收缩，有序删除（即从 N-1 到 0）

🚀 两大核心组成：

• headless Service
  • 用于定义网络标志（DNS domain）
  • Domain Name Server：域名服务
  • 将域名与 ip 绑定映射关系
  • 服务名 => 访问路径（域名） => ip
• volumnClaimTemplate:
  • 用于创建 PersistentVolumes持久卷

StatefulSet 中每个 Pod 的 DNS 格式为：

statefulSetName-{0..N1}.serviceName.namespace.svc.cluster.local

• serviceName 为 Headless Service 的名字
• 0..N-1 为 Pod 所在的序号，从 0 开始到 N-1
• statefulSetName 为 StatefulSet 的名字
• namespace 为服务所在的 namespace，Headless Service 和 StatefulSet 必须在相同的 namespace
• .cluster.local 为 Cluster Domain

StatefulSet在使用的时候有如下四点需要注意：

• kubernetes v1.5 版本以上才支持
• 所有Pod的Volume必须使用PersistentVolume或者是管理员事先创建好
• 为了保证数据安全，删除StatefulSet时不会删除Volume
• StatefulSet 需要一个 Headless Service 来定义 DNS domain，需要在 StatefulSet 之前创建好

DeamonSet

DaemonSet 保证在每个 Node 上都运行一个容器副本

k8s将会按照指定的规则将此种类型的pod自动的部署到node上运行

常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：

• 日志收集，比如 fluentd，logstash 等
• 系统监控，比如 Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond 等
• 系统程序，比如 kube-proxy, kube-dns, glusterd, ceph 等

如上图，通过nodeSelector自动配置节点上标记type=logs的节点，然后将pod在对应的节点上部署完成守护进程的创建

任务

• Job：一次性任务，运行完成后Pod销毁，不再重新启动新容器。
• CronJob：CronJob 是在 Job 基础上加上了定时功能。

1.3.2：服务发现(重中之重)

1.3.2.1：service

Service实现的是k8s集群内部网络调用和负载均衡

不同节点的同一类服务交给同一个Service管理, 是用来实现东西流量的，也就是微服务之间的互相调用

“Service” 简写 “svc”。Pod 不能直接提供给外网访问，而是应该使用 service。

Service 就是把 Pod 暴露出来提供服务，Service 才是真正的“服务”，它的中文名就叫“服务”。

可以说 Service 是一个应用服务的抽象，定义了 Pod 逻辑集合和访问这个 Pod 集合的策略。

Service 代理 Pod 集合，对外表现为一个访问入口，访问该入口的请求将经过负载均衡，转发到后端 Pod 中的容器。

1.3.2.2：Ingress

Ingress实现将k8s内部服务暴露给外网访问的服务

颇有一种spring cloud gateway的感觉，是用来实现南北流量的，网关层调用微服务

Ingress 可以提供外网访问 Service 的能力。可以把某个请求地址映射、路由到特定的 service。

ingress 需要配合 ingress controller 一起使用才能发挥作用，ingress 只是相当于路由规则的集合而已，真正实现路由功能的，是 Ingress Controller

ingress controller 和其它 k8s 组件一样，也是在 Pod 中运行。

1.3.3：存储

volumn

数据卷，共享 Pod 中容器使用的数据。用来放持久化的数据，比如数据库数据。

CSI

Container Storage Interface 是由来自 Kubernetes、Mesos、Docker 等社区成员联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。

CSI 规范定义了存储提供商实现 CSI 兼容的 Volume Plugin 的最小操作集和部署建议。CSI 规范的主要焦点是声明 Volume Plugin 必须实现的接口。

1.3.4：特殊类型配置

secret

Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。Secret 可以以 Volume 或者环境变量的方式使用。

Secret 有三种类型：

类型	说明
Service Account	用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中
Opaque	base64 编码格式的 Secret，用来存储密码、密钥等
kubernetes.io/dockerconfigjson	用来存储私有 docker registry 的认证信息

downwardAPI

downwardAPI 这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的，而是让 pod 里的容器能够直接获取到这个 pod 对象本身的一些信息。

downwardAPI 提供了两种方式用于将 pod 的信息注入到容器内部：

环境变量：用于单个变量，可以将 pod 信息和容器信息直接注入容器内部

volume 挂载：将 pod 信息生成为文件，直接挂载到容器内部中去

ConfigMap

用来放配置，与 Secret 是类似的，只是 ConfigMap 放的是明文的数据，Secret 是密文存放。

1.3.5：其他

Role

Role 是一组权限的集合，例如 Role 可以包含列出 Pod 权限及列出 Deployment 权限

Role 用于给某个 Namespace 中的资源进行鉴权。

RoleBinding

将 Subject 绑定到 Role，RoleBinding 使规则在命名空间内生效。

2：资源清单

可以通过json或者yaml的方式配置资源清单，完成各种资源的操作

对于yaml的清单配置项，可以通过我的这个文章了解详细的信息

3：对象和规约

对象是用来完成一些任务的，是持久的，是有目的性的

因此 kubernetes 创建一个对象后，将持续地工作以确保对象存在。

当然，kubernetes 并不只是维持对象的存在这么简单，kubernetes 还管理着对象的方方面面。

每个 Kubernetes 对象包含两个嵌套的对象字段，它们负责管理对象的配置，他们分别是 “spec” 和 “status” 。

3.1：规约spec

“spec” 是 “规约”、“规格” 的意思，spec 是必需的，它描述了对象的期望状态(希望对象所具有的特征)。

当创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息

3.2：状态status

表示对象的实际状态，该属性由 k8s 自己维护

k8s 会通过一系列的控制器对对应对象进行管理，让对象尽可能的让实际状态与期望状态重合。