第1章：基础知识

千与千寻吖
104 阅读26分钟

1. Kubernetes特性

Kubernetes 是一种用于在一组主机上运行和协同容器化应用程序的系统。它旨在提供一个可预测、可扩展且高可用的平台，以全面管理容器化应用程序和服务的生命周期。

用户可以定义应用程序的运行方式、与其他应用程序或外部世界的交互途径，并能实现服务的扩容和缩容、执行平滑的滚动更新，以及在不同版本的应用程序间调度流量（例如，进行 A/B 测试或回滚有问题的部署）。Kubernetes 提供了一系列接口和可组合的平台原语，使用户能够以高度的灵活性、可靠性和效率来定义及管理应用程序。

简单总结起来，它具有以下几个重要特性：

  1. 自动装箱 (Automatic Bin Packing)
    基于容器技术，系统会根据容器对 CPU 和内存等资源的需求，自动将其调度到合适的节点上，同时满足各种约束条件。这种调度机制允许将关键型和非关键型工作负载混合部署在同一节点，从而显著提升资源利用率。
  2. 自我修复 (Self-Healing)
    系统具备强大的自愈能力：自动重启故障的容器、在节点宕机后重新调度其上运行的容器、对健康检查失败的容器进行关闭并重新创建等，确保应用程序始终处于预期状态。
  3. 水平扩展 (Horizontal Scaling)
    支持通过简单的命令或用户界面手动扩展应用规模，也支持基于 CPU 利用率等指标自动进行水平扩展（HPA）。
  4. 服务发现和负载均衡 (Service Discovery & Load Balancing)
    Kubernetes 为每个 Service 分配一个唯一的 DNS 名称（通过 CoreDNS 等组件实现），从而实现服务发现。集群内的应用可以直接通过该名称访问服务。Service 本身通过iptables或ipvs提供了内置的负载均衡机制，将请求自动分发到后端健康的 Pod。
  5. 自动发布和回滚 (Automated Rollouts & Rollbacks)
    Kubernetes 支持 “滚动更新” 策略来部署应用程序或更新配置。更新过程会逐步用新实例替换旧实例，并持续监控应用的健康状态。如果在更新过程中出现问题，系统会立即自动回滚到之前的稳定版本。
  6. 密钥和配置管理 (Secret & Configuration Management)
    通过ConfigMap对象，可以将配置信息与 Docker 镜像解耦，实现不重新构建镜像即可动态修改应用配置。对于敏感数据（如密码、OAuth 令牌、SSH 密钥等），则使用Secret对象进行存储和管理，既方便了应用部署，也提供了更高的安全性。
  7. 存储编排 (Storage Orchestration)
    可以自动按需为 Pod 挂载各种类型的存储系统，包括本地存储、公有云提供商（如 AWS EBS、GCP Persistent Disk）的云存储，以及网络存储系统（如 NFS、iSCSI、GlusterFS、Ceph 等）。通过容器存储接口 (CSI) ，第三方存储提供商可以轻松集成。
  8. 批量处理执行 (Batch Execution)
    除了长期运行的服务（Service），Kubernetes 同样支持运行一次性任务（Jobs）和定时任务（CronJobs），非常适合进行批处理作业和持续集成（CI）流水线。这些任务也享受平台的自愈能力，确保任务完成。

2. 概念和术语

1.jpg

一、集群组件

1. Master：

指的是集群的控制节点，每个 k8s 集群里至少需要一个 Master 节点来负责整个集群的管理和控制，所有控制命令都是发给它，它来负责具体的调度和执行。

2. Node：

是 k8s 集群中用于运行 Pod 的机器，Node 为整个集群提供可用的集群资源，比如用于保持数据、运行作业、创建网络路由等。如果某个 Node节点宕机，其上的工作负载会被 Master 自动转移到其它节点上去。

二、资源抽象

1. 容器组（Pod）:

Kubernetes中最小的资源单位。由位于同一节点上若干容器组成，彼此共享网络命名空间和存储卷（Volume）。Pod是Kubernetes中进行管理的最小资源单位，是最为基础的概念。跟容器类似，Pod是短暂的，随时可变的，通常不带有状态。一般每个Pod中除了应用容器外，还包括一个初始的pause容器，完成网络和存储空间的初始化；

2. 服务（Service）：

对外提供某个特定功能的一组Pod（可通过标签来选择）和所关联的访问配置。由于Pod的地址是不同的，而且可能改变，直接访问Pod将无法获得稳定的业务。Kubernetes通过服务提供唯一固定的访问地址（如IP地址或者域名），不随后面Pod改变而变化。用户无须关心具体的Pod信息；

3. 存储卷（Volume）：

存储卷类似Docker中的概念，提供数据的持久化存储（如Pod重启后），并支持更高级的生命周期管理和参数指定功能，支持多种本地和云存储类型；持久化的存储以插件的形式提供为 PersistentVolume 资源，用户通过请求某个类型的 PersistentVolumeClaim 资源，来从匹配的持久化存储卷上获取绑定的存储。（现代存储通过 CSI 驱动集成）

4. 命名空间（Namespace）:

Kubernetes通过命名空间来实现虚拟化，将同一组物理资源虚拟为不同的抽象集群，避免不同租户的资源发生命名冲突，另外可以进行资源限额。

三、控制器抽象

1. 副本集（ReplicaSet）：

基于Pod的抽象。使用它可以让集群中始终维持某个Pod的指定副本数的健康实例。副本集中的Pod相互并无差异，可以彼此替换。

2. 部署（Deployment）：

管理Pod或副本集，并且支持升级操作。部署控制器可以提供提供比副本集更方便的操作，推荐使用；

3. 状态集（StatefulSet）：

管理带有状态的应用。相比部署控制器，状态集可以为Pod分配独一无二的身份，确保在重新调配等操作时也不会相互替换。自1.9版本开始正式支持；

4. Daemon集（DaemonSet）：

确保节点上肯定运行某个Pod，一般用来采集日志（如logstash）、监控节点（如collectd）或提供存储（如glusterd）使用；

5. 任务（Job）：

类似云里面的自动扩展组，根据 Pod 的使用率（典型如 CPU）自动调整一个部署里面 Pod 的个数，保障服务可用性；（现代 HPA (autoscaling/v2) 支持多指标（内存、自定义指标等） ）

6. 横向Pod扩展器（Horizontal Pod Autoscaler, HPA）：

类似云里面的自动扩展组，根据Pod的使用率（典型如CPU）自动调整一个部署里面Pod的个数，保障服务可用性；

7. 入口控制器（Ingress Controller）：

定义外部访问集群中资源的一组规则，用来提供七层代理和负载均衡服务。（现代 Kubernetes 使用 IngressClass 资源来指定和管理不同的 Ingress 控制器）

四、辅助概念

1. 标签（Label）：

键值对，可以标记到资源对象上，用来对资源进行分类和筛选；

2. 选择器（Selector）：

基于标签概念的一个正则表达式，可通过标签来筛选出一组资源；

3. 注解（Annotation）：

键值对，可以存放大量任意数据，一般用来添加对资源对象的细说明，可供其他工具处理。

4. 秘密数据（Secret）：

存放敏感数据，例如用户认证的口令等；

5. 名字（Name）：

用户提供给资源的别名，同类资源不能重名；

6. 持久化存储（PersistentVolume）：

确保数据不会丢失；

7. 资源限额（Resource Quotas）：

用来限制某个命名空间下对资源的使用，开始逐渐提供多租户支持；

8. 安全上下文（Security Context）：

应用到容器上的系统安全配置，包括uid、gid、capabilities、SELinux角色等；

9. 服务账号（Service Accounts）：

操作资源的用户账号。

3.集群组件

一、结构拓扑

2.jpg

  1. 一个典型的Kubernetes集群由多个工作节点（worker node）和一个集群控制平面（control plane，即Master），以及一个集群状态存储系统（etcd）组成。其中Master节点负责整个集群的管理工作，为集群提供管理接口，并监控和编排集群中的各个工作节点。
  2. Master节点主要由apiserver、controller-manager和scheduler三个组件，以及一个用于集群状态存储的etcd存储服务组成，而每个Node节点则主要包含kubelet、kube-proxy及容器引擎（Docker是最为常用的实现）等组件。此外，完整的集群服务还依赖于一些附加组件，如KubeDNS等。

二、Master组件

Kubernetes 的集群控制平面由多个组件组成，这些组件可统一运行于单一 Master 节点，也可以以多副本的方式同时运行于多个节点，以为 Master 提供高可用功能，甚至还可以运行于 Kubernetes 集群自身之上。Master 主要包含以下几个组件。

1. API服务器（API Server）

API Server负责输出RESTful风格的Kubernetes API，它是发往集群的所有REST操作命令的接入点，并负责接收、校验并响应所有的REST请求，结果状态被持久存储于etcd中。因此，API Server是整个集群的网关。

2. 控制器管理器（Controller Manager）

Controller Manager 用于执行大部分的集群层次的功能，它包含多个控制循环（Control Loops） ，既执行生命周期功能(例如：命名空间创建和生命周期、事件垃圾收集、已终止垃圾收集、级联删除垃圾收集、node垃圾收集)，也执行API业务逻辑（例如：pod的弹性扩容）。控制管理提供自愈能力、扩容、应用生命周期管理、服务发现、路由、服务绑定和提供。

3. 调度器（Scheduler）

Kubernetes是用于部署和管理大规模容器应用的平台，根据集群规模的不同，其托管运行的容器很可能会数以千计甚至更多。API Server确认Pod对象的创建请求之后，便需要由Scheduler根据集群内各节点的可用资源状态，以及要运行的容器的资源需求做出调度决策。另外，Kubernetes还支持用户自定义调度器。

4. 云控制器管理器（Cloud Controller Manager）

在云环境中运行 Kubernetes 时，CCM 将与底层云提供商（AWS, GCP, Azure 等）交互的控制器逻辑（如负载均衡器管理、节点路由）从 Kubernetes 核心代码中剥离出来，成为一个可插拔的组件，使架构更清晰。

三、集群状态存储（ETCD）

  1. Kubernetes集群的所有状态信息都需要持久存储于存储系统etcd中，etcd是由CoreOS基于Raft协议开发的分布式键值存储，可用于服务发现、共享配置以及一致性保障（如数据库主节点选择、分布式锁等）。
  2. etcd是独立的服务组件，并不隶属于Kubernetes集群自身。生产环境中应该以etcd集群的方式运行以确保其服务可用性。
  3. etcd不仅能够提供键值数据存储，而且还为其提供了监听（watch）机制，用于监听和推送变更。Kubernetes集群系统中，etcd中的键值发生变化时会通知到API Server，并由其通过watch API向客户端输出。基于watch机制，Kubernetes集群的各组件实现了高效协同。

四、Node组件

Node负责提供运行容器的各种依赖环境，并接受Master的管理。每个Node主要由以下几个组件构成。

1. Node的核心代理程序kubelet

kubelet是运行于工作节点之上的守护进程，它从API Server接收关于Pod对象的配置信息并确保它们处于期望的状态（desired state，后文不加区别地称之为“目标状态”）。kubelet会在API Server上注册当前工作节点，定期向Master汇报节点资源使用情况，并通过cAdvisor监控容器和节点的资源占用状况。

每个 Node 都要提供一个容器运行时（Container Runtime）环境，它负责下载镜像并运行容器。kubelet通过容器运行时接口（CRI）  以插件的方式载入配置的容器环境（如containerd或CRI-O）。这种方式清晰地定义了各组件的边界。目前，containerd是推荐的容器运行时。

2. kube-proxy

每个工作节点都需要运行一个kube-proxy守护进程，它能够按需为Service资源对象生成iptables或ipvs规则，从而捕获访问当前Service的ClusterIP的流量并将其转发至正确的后端Pod对象。

3. 容器运行时（Container Runtime）

负责运行容器的软件，例如 containerd (当前推荐) 或 CRI-O。它通过 CRI 与 kubelet 通信。

五、核心附件

Kubernetes集群还依赖于一组称为“附件”（add-ons）的组件以提供完整的功能，它们通常是由第三方提供的特定应用程序，且托管运行于Kubernetes集群之上。

1. KubeDNS：

在 Kubernetes 集群中调度运行提供 DNS 服务的 Pod，同一集群中的其他 Pod 可使用此 DNS 服务解决主机名。Kubernetes 自 1.11 版本开始默认使用 CoreDNS 项目为集群提供服务注册和服务发现的动态名称解析服务，之前的版本中用到的是 kube-dns 项目。CoreDNS 已成为 Kubernetes 默认的、标准的 DNS 服务器。

2. Kubernetes Dashboard

Kubernetes集群的全部功能都要基于Web的UI，来管理集群中的应用甚至是集群自身。

3. Ingress Controller

Service是一种工作于传统层的负载均衡器，而Ingress是在应用层实现的HTTP（s）负载均衡机制。不过，Ingress资源自身并不能进行“流量穿透”，它仅是一组路由规则的集合，这些规则需要通过Ingress控制器（Ingress Controller）发挥作用。目前，此类的可用项目有Nginx、Traefik、Envoy及HAProxy等。

4. Metrics Server

一个集群范围的资源使用数据聚合器，为 HPA 和集群管理功能（如kubectl top）提供核心指标（CPU 和内存）。

4.抽象对象

Kubernetes对集群中的资源进行了不同级别的抽象，每个资源都是一个REST对象，通过API进行操作，通过json或yaml格式的模板文件进行定义。

一、抽象资源对象

1.  容器组（Pod）

在Kubernetes中，并不直接操作容器，最小的管理单位是容器组（Pod）。容器组由一个或多个容器组成，Kubernetes围绕容器组进行创建、调度、停止等生命周期管理。

同一个容器组中，各个容器共享命名空间（包括网络、IPC、文件系统等容器支持的命名空间）、cgroups限制和存储卷。这意味着同一个容器组中，各个应用可以很方便地相互进行访问，比如通过localhost地址进行网络访问，通过信号量和共享内存进行进程间通信等，类似经典场景中运行在同一个操作系统中的一组进程。可以简单地将一个Pod当作是一个抽象的“虚拟机”，里面运行若干个不同的进程（每个进程实际上就是一个容器）。

实现上，是先创建一个gcr.io/google_containers/pause容器，创建相关命名空间，然后创建Pod中的其他应用容器，并共享pause容器的命名空间。

组成容器组的若干容器往往是存在共同的应用目的，彼此关联十分紧密，例如一个Web应用与对应的日志采集应用、状态监控应用。如果单纯把这些相关的应用放一个容器里面，又会造成过度耦合，管理、升级都不方便。

容器组既保持了容器轻量解耦的特性，又提供了调度操作的便利性，在实践中提供了比单个容器更为灵活和更有意义的抽象。

2. 服务（Service）

服务（Service）的提出，主要是要解决Pod地址可变的问题。由于Pod随时可能发生故障，并可能在其他节点上被重启，它的地址是不能保持固定的。因此，用一个服务来代表提供某一类功能（可以通过标签来筛选）的一些Pod，并分配不随Pod位置变化而改变的虚拟访问地址（Cluster IP）。

典型情况是，比如网站的后端服务，可能有多个Pod都运行了后端处理程序，它们可以组成一个服务。前端只需通过服务的唯一虚拟地址来访问即可，而无须关心具体是访问到了哪个Pod。可见，服务跟负载均衡器实现的功能很相似。

根据访问方式的不同，服务可以分为如下几种类型：

  • ClusterIP：提供一个集群内部的地址，该地址只能在集群内解析和访问。ClusterIP是默认的服务类型；
  • NodePort：在每个集群节点上映射服务到一个静态的本地端口（默认范围为30000～32767）。从集群外部可以直接访问，并自动路由到内部自动创建的ClusterIP；
  • LoadBalancer：使用外部的路由服务，自动路由访问到自动创建的NodePort和ClusterIP；
  • ExternalName：将服务映射到externalName域指定的地址，需要1.7以上版本kube-dns的支持。

组成一个服务的Pod可能是属于不同复制控制器的，但服务自身是不知道复制控制器的存在的。

3. 存储卷（Volume）

即容器挂载的数据卷，跟Pod有一致的生命周期，Pod生存过程（包括重启）中，数据卷跟着存在；Pod退出，则数据卷跟着退出。

几个比较常见的数据卷类型包括：emptyDir、hostPath、gcePersistentDisk、awsElastic-BlockStore、nfs、gitRepo、secret。

  • emptyDir：当Pod创建的时候，在节点上创建一个空的挂载目录，挂载到容器内。当Pod从节点离开（例如删除掉）的时候，自动删除挂载目录内数据。节点上的挂载位置可以为物理硬盘或内存。这一类的挂载适用于非持久化的存储，例如与Pod任务相关的临时数据等。除此之外，其他存储格式大都是持久化的；
  • hostPath：将节点上某已经存在的目录挂载到Pod中，Pod退出后，节点上的数据将保留；
  • gcePersistentDisk：使用GCE的Persistent Disk服务，Pod退出后，会保留数据；
  • awsElasticBlockStore：使用AWS的EBS Volume服务，数据也会持久化保留；
  • nfs：使用NFS协议的网络存储，也是持久化数据存储；
  • gitRepo：挂载一个空目录到Pod，然后clone指定的git仓库代码到里面，适用于直接从仓库中给定版本的代码来部署应用；
  • secret：用来传递敏感信息（如密码等），基于内存的tmpfs，挂载临时秘密文件。
  • 持久化的存储以插件的形式提供为PersistentVolume资源，用户通过请求某个类型的PersistentVolumeClaim资源，来从匹配的持久化存储卷上获取绑定的存储。

二、控制器抽象对象

控制器抽象对象是基于对所操控对象的进一步抽象，附加了各种资源的管理功能，目前主要包括副本集、部署、状态集、Daemon集、任务等。

1. 副本集（ReplicaSet）和部署（Deployment）

在Kubernetes看来，Pod资源是可能随时发生故障的，并不需要保证Pod的运行，而是在发生失败后重新生成。Kubernetes通过复制控制器来实现这一功能。

用户申请容器组后，复制控制器将负责调度容器组到某个节点上，并保证它的给定份数（replica）正常运行。当实际运行Pod份数超过数目，则终止某些Pod；当不足，则创建新的Pod。一般建议，即使Pod份数是1，也要使用复制控制器来创建，而不是直接创建Pod。

可以将副本集类比为进程的监管者（supervisor）的角色，只不过它不光能保持Pod的持续运行，还能保持集群中给定类型Pod同时运行的个数为指定值。Pod是临时性的，可以随时由副本集创建或者销毁，这意味着要通过Pod自身的地址访问应用是不能保证一致性的。Kubernetes通过服务的概念来解决这个问题。

从1.2.0版本开始，Kubernetes将正式引入部署机制来支持更灵活的Pod管理，从而用户无须直接跟复制控制器打交道了。部署代表用户对集群中应用的一次更新操作，在副本集的基础上还支持更新操作。每次滚动升级（rolling-update），会自动将副本集中旧版本的Pod逐渐替换为新的版本。

另外，副本集也可以支持成为“横向Pod扩展器”的操作对象。

2. 状态集（StatefulSet）

通常情况下，使用容器的应用都是不带状态的，意味着部署同一个应用的多个Pod彼此可以替换，而且生命周期可以是很短暂的。任何一个Pod退出后，Kubernetes在集群中可以自动创建一个并按照调度策略调度到节点上。无状态的应用时候，关心的主要是副本的个数，而不关心名称、位置等。与此对应，某些应用需要关心Pod的状态（包括各种数据库和配置服务等），挂载独立的存储。一旦当某个Pod故障退出后，Kubernetes会创建同一命名的Pod，并挂载原来的存储，以便Pod中应用继续执行，实现了该应用的高可用性。

状态集正是针对这种需求而设计的，提供比副本集和部署更稳定可靠的运行支持。

3. Daemon集（DaemonSet）

Daemon集适合于长期运行在后台的伺服类型应用，例如对节点的日志采集或状态监控等后台支持服务。

Daemon集的应用会确保在指定类型的每个节点上都运行一个该应用的Pod。可能是集群中所有节点，也可能是指定标签的一类节点。

4. 任务（Job）

不同于长期运行的应用，任务（Job）代表批处理类型的应用。任务中应用完成某一类的处理即可退出，有头有尾。例如，计算Pi到多少位，可以指定若干个Pod成功完成计算，即算任务成功执行。

5. 横向Pod扩展器（Horizontal Pod Autoscaler, HPA）

横向Pod扩展器（Horizontal Pod Autoscaler, HPA）解决应用波动的情况。类似云里面的自动扩展组，扩展器根据Pod的使用率（典型如CPU、内存等）自动调整一个部署里面Pod的个数，保障服务在不同压力情况下保证平滑的输出效果。

控制管理器会定期检查性能指标，在满足条件时候触发横向伸缩。Kubernetes 1.6 版本开始支持基于多个指标的伸缩。（现代 HPA (v2) 功能更强大，支持自定义和外部指标）

三、其他抽象对象

1. 标签（Label）

标签（Label）是一组键值对，用来标记所绑定对象（典型的就是Pod）的识别属性，进而可以分类。比如name=apache|nginx、type=web|db、release=alpha|beta|stable、tier=frontend|backend等。另外，Label键支持通过/来添加前缀，可以用来标注资源的组织名称等。一般的，前缀不能超过253个字符，键名不能超过63个字符。

标签所定义的属性是不唯一的，这意味着不同资源可能带有相同的标签键值对。这些属性可以将业务的相关信息绑定到对象上，用来对资源对象进行分类和选择过滤。

2. 注解（Annotation）

注解（Annotation）跟标签很相似，也是键值对，但并非用来标识对象，同时可以存储更多更复杂的信息。不同的是，注解并不是为了分类资源对象，而是为了给对象增加更丰富的描述信息。这些信息是任意的，数据量可以很大，可以包括各种结构化、非结构化的数据。

常见的注解包括时间戳、发行信息、开发者信息等，一般是为了方便用户查找相关线索。

3. 选择器（Selector）

基于资源对象上绑定的标签信息，选择器（Selector）可以通过指定标签键值对来过滤出一组特定的资源对象。

选择器支持的语法包括基于等式（Equality-based）的，和基于集合（Set-based）的。

基于等式的选择，即通过指定某个标签是否等于某个值，例如env=production或者tier! =frontend等。多个等式可以通过AND逻辑组合在一起。

基于集合的选择，即通过指定某个标签的值是否在某个集合内，例如env in (staging, production)。

4. 秘密数据（Secret）

秘密数据（Secret）资源用来保存一些敏感的数据，这些数据（例如密码）往往不希望别的用户看到，但是在启动某个资源（例如Pod）的时候需要提供。通过把敏感数据放到Secret里面，用户只需要提供Secret的别名即可使用。

在对应容器（secret-test-pod.test-container）内，通过环境变量SECRETUSERNAME和SECRET_USERNAME和SECRET_PASSWORD即可获取到原始的用户名和密码信息。

此外，还可以采用数据卷的方式把秘密数据的值以文件形式放到容器内。通常，秘密数据不要超过1 MB。

在整个过程中，只有秘密数据的所有人和最终运行的容器（准确的说，需要是同一个服务账号下面的）能获取原始敏感数据，只接触到Pod定义模板的人是无法获取到的。

5. UID和名字

Kubernetes用UID和名字（Name）来标识对象。其中，UID是全局唯一的，并且不能复用；而名字则仅仅要求对某种类型的资源（在同一个命名空间内）内是唯一的，并且当某个资源移除后，其名字可以被新的资源复用。

这意味着，可以创建一个Pod对象，命名为test，同样可以创建一个复制控制器，命名也为test。一般的，名字字符串的长度不要超过253个字符。

6. 命名空间

命名空间（Namespace）用来隔离不同用户的资源，类似租户或项目的概念。默认情况下，相同命名空间中的对象将具有相同的访问控制策略。

同一个命名空间内，资源不允许重名，但不同命名空间之间，允许存在重名。用户在创建资源的时候可以通过–namespace=<some_namespace>来指定所属的命名空间。

Kubernetes集群启动后，会保留两个特殊的命名空间：

  • default：资源未指定命名空间情况下，默认属于该空间；
  • kube-system：由Kubernetes系统自身创建的资源。

另外，大部分资源都属于某个命名空间，但部分特殊资源，如节点、持久存储等不属于任何命名空间。

7. 污点和容忍

污点（Taint）和容忍（Toleration）用于辅助管理Pod到工作节点的调度过程。具有某个污点的工作节点，在不容忍的Pod看来，要尽量避免调度到它上面去。

通常情况下，可以为一个工作节点注明若干污点，只有对这些污点容忍的Pod，才可以被调度到这些具有污点的节点上。

5.镜像文件下载

k8s.gcr.io 长期被墙，导致 k8s 的镜像经常无法获取。可以通过以下方式解决

使用阿里镜像服务加速

1. github创建仓库，新建Dockerfile文件，内容为FROM 镜像名称

2. 登陆阿里云的容器镜像服务然后点击创建镜像仓库

3. 代码源绑定github账号

4. 构建——添加规则

5. 根据提示使用镜像

6. pull镜像，修改tag

`docker tag registry.cn-hangzhou.aliyuncs.com/cuiliang_images/cuiliang_images:1 k8s.gcr.io/metrics-server-amd64:v0.3.6`

7. 导出镜像

`docker save -o metrics-server.tar k8s.gcr.io/metrics-server-amd64:v0.3.6`

8. 导入镜像

`docker load -i metrics-server.tar`

使用代理软件下载镜像导入

# 在科学工具环境下，下载镜像
docker pull registry.k8s.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
# 导出镜像
docker save -o nfs.tar registry.k8s.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2 

# k8s节点导入镜像
nerdctl -n k8s.io load -i nfs.tar

配置代理地址

docker 配置代理地址

创建 dockerd 相关的 systemd 目录，这个目录下的配置将覆盖 dockerd 的默认配置

mkdir -p /etc/systemd/system/docker.service.d

新建配置文件 /etc/systemd/system/docker.service.d/http-proxy.conf，这个文件中将包含环境变量

[Service]
Environment="HTTP_PROXY=proxy.example.com:80"
Environment="HTTPS_PROXY=proxy.example.com:443"

如果你自己建了私有的镜像仓库，需要 dockerd 绕过代理服务器直连，那么配置 NO_PROXY 变量：

[Service]
Environment="HTTP_PROXY=http://192.168.8.10:7890"
Environment="HTTPS_PROXY=http://192.168.8.10:7890"
Environment="NO_PROXY=hub-mirror.c.163.com,mirror.ccs.tencentyun.com,harbor.local.com,harbor.cuiliangblog.cn"

多个 NO_PROXY 变量的值用逗号分隔，而且可以使用通配符（ ），极端情况下，如果 NO_PROXY=，那么所有请求都将不通过代理服务器。

重新加载配置文件，重启 dockerd

systemctl daemon-reload
systemctl restart docker

检查确认环境变量已经正确配置：

systemctl show --property=Environment docker

这样配置后，应该可以正常拉取 docker 镜像。

containerd 配置代理地址

编辑 containerd 的 systemd 服务配置

# mkdir -p /etc/systemd/system/containerd.service.d
# vim /etc/systemd/system/containerd.service.d/http-proxy.conf

添加以下内容（根据你的代理地址调整）

[Service]
Environment="HTTP_PROXY=http://192.168.8.10:7890"
Environment="HTTPS_PROXY=http://192.168.8.10:7890"
Environment="NO_PROXY=hub-mirror.c.163.com,mirror.ccs.tencentyun.com,harbor.local.com,harbor.cuiliangblog.cn"

重新加载并重启服务

systemctl daemon-reload
systemctl restart containerd
systemctl show containerd --property=Environment

可以通过 ctr 命令测试拉取镜像：

crictl pull docker.io/library/nginx:alpine

如果配置正确，镜像应能正常拉取。

使用coding海外节点拉取镜像

具体操作参考文档：www.cuiliangblog.cn/detail/arti…

avatar
文章
阅读
粉丝