关于kubernetes:K3S-HelmNFS最小化测试安装部署只需十分钟

作者：郝建伟

k3s 简介

官网文档：k3s

什么是k3s

k3s 是一个轻量级的 Kubernetes 发行版它针对边缘计算、物联网等场景进行了高度优化。k3s 有以下加强性能：

1. 打包为单个二进制文件。
2. 应用基于 sqlite3 的轻量级存储后端作为默认存储机制。同时反对应用 etcd3、MySQL 和 PostgreSQL 作为存储机制。
3. 封装在简略的启动程序中，通过该启动程序处理很多简单的 TLS 和选项。
4. 默认状况下是平安的，对轻量级环境有正当的默认值。
5. 增加了简略但功能强大的batteries-included性能，例如：本地存储提供程序，服务负载均衡器，Helm controller 和 Traefik Ingress controller。
6. 所有 Kubernetes control-plane 组件的操作都封装在单个二进制文件和过程中，使 k3s 具备自动化和治理包含证书散发在内的简单集群操作的能力。

7. 最大水平加重了内部依赖性，k3s 仅须要 kernel 和 cgroup 挂载。 k3s 软件包须要的依赖项包含：

   containerdFlannelCoreDNSCNI主机实用程序（iptables、socat 等）Ingress controller（Traefik）嵌入式服务负载均衡器（service load balancer）嵌入式网络策略控制器（network policy controller）

为什么叫 k3s?

k3s内存占用是k8s的一半kubernetes是一个10个字母的单词，简写为k8skubenetes的一半是5个字母，简写为k3s

实用场景

k3s 实用于以下场景：

1. 边缘计算-Edge
2. 物联网-IoT
3. CI
4. Development
5. ARM
6. 嵌入 k8s

因为运行 k3s 所需的资源绝对较少，所以 k3s 也实用于开发和测试场景。在这些场景中，如果开发或测试人员须要对某些性能进行验证，或对某些问题进行重现，那么应用 k3s 不仅可能缩短启动集群的工夫，还可能缩小集群须要耗费的资源。

架构介绍

k3s server 是运行k3s server命令的机器（裸机或虚拟机），而 k3s worker 节点是运行 k3s worker命令的机器

单节点架构

k3s 单节点集群的架构如下图所示，该集群有一个内嵌 SQLite 数据库的单节点 k3s server。在这种配置中，每个 worker 节点都注册到同一个 server 节点。k3s 用户能够通过调用 server 节点上的 k3s API 来操作 Kubernetes 资源。

高可用架构

尽管单节点 k3s 集群能够满足各种用例，但对于 Kubernetes control-plane 的失常运行至关重要的环境，您能够在高可用配置中运行 k3s。一个高可用 k3s 集群由以下几个局部组成：

1. k3s Server 节点：两个或更多的server节点将为 Kubernetes API 提供服务并运行其余 control-plane 服务
2. 内部数据库：与单节点 k3s 设置中应用的嵌入式 SQLite 数据存储相同，高可用 k3s 须要挂载一个external database内部数据库作为数据存储的媒介。

k3s高可用架构:

固定 worker 节点的注册地址

在高可用 k3s server 配置中，每个节点还必须应用固定的注册地址向 Kubernetes API 注册，注册后，worker 节点间接与其中一个 server 节点建设连贯

如下图所示：

注册 worker 节点

Agent 节点用k3s worker过程发动的 websocket 连贯注册，连贯由作为代理过程一部分运行的客户端负载均衡器保护。

Agent 将应用节点集群 secret 以及随机生成的节点明码向 k3s server 注册，明码存储在 /etc/rancher/node/password门路下。k3s server 将把各个节点的明码存储为 Kubernetes secrets，随后的任何尝试都必须应用雷同的明码。节点明码机密存储在kube-system命名空间中，名称应用模板.node-password.k3s

留神:    在 k3s v1.20.2 之前，k3s server 将明码存储在/var/lib/rancher/k3s/server/cred/node-passwd的磁盘上。    如果您删除了 worker 的/etc/rancher/node目录，则须要为该 worker 从新创立密码文件，或者从 server 中删除该条目。    通过应用--with-node-id标记启动 k3s server 或 worker，能够将惟一的节点 ID 附加到主机名中。

主动部署的清单

位于目录门路/var/lib/rancher/k3s/server/manifests 的清单在构建时被捆绑到 k3s 二进制文件中将由rancher/helm-controller在运行时装置。

k3s默认容器运行时

k3s默认应用 containerd 作为容器运行时在 goroutine 中以 子过程 形式 启动 containerd

验证:

ps aux | grep “k3s server”

ps -A -ostat,pid,ppid,cmd |grep 7897

筹备工作

敞开SELinux

# 长期敞开setenforce 0# 永恒敞开sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

敞开swap

# 长期敞开swap分区，以后会话失效，重启生效swapoff -a  # 永恒敞开swap分区sed -ri 's/.*swap.*/#&/' /etc/fstab

设置主机名

# 长期批改主机名:hostname newname（本文波及四台机器：一主三从）hostname k3s-master1hostname k3s-node1hostname k3s-node2hostname k3s-node3注：这种形式是立刻失效，然而在服务器重启后会复原成原来的名字# 永久性批改主机名：批改/etc/sysconfig/network文件内容vim /etc/sysconfig/networkNETWORKING=yesHOSTNAME=localhost1注：这种形式不会立刻失效，须要重启服务器才会失效，且永久性批改

离线装置

概述

你能够应用两种不同的办法在离线环境中装置 k3s。离线环境是不间接连贯到 Internet 的任何环境。你能够部署一个公有镜像仓库，或者你能够手动部署镜像，比方用于小型集群。

离线装置的过程次要分为以下两个步骤：

步骤 1：部署镜像

步骤 2：装置 k3s

离线降级 k3s 版本: 实现离线装置 k3s 后，您还能够通过脚本降级 k3s 版本，或启用主动降级性能，以放弃离线环境中的 k3s 版本与最新的 k3s 版本同步。

部署公有镜像仓库

前提条件

搭建公有仓库 ，例如 harbor仓库

搭建参考Harbor装置

创立镜像仓库 YAML

请依照 K3S 公有镜像仓库配置创立并配置registry.yaml文件。实现后，当初能够转到上面的[装置 k3s]局部，开始装置 K3

手动部署镜像
前提条件

假如曾经在离线环境中创立了节点。
这种办法须要您手动将必要的镜像部署到每个节点，实用于运行无奈部署镜像仓库的边缘部署场景。

操作步骤

请依照以下步骤筹备镜像目录和 k3s 二进制文件

1. 从k3s GitHub Release页面获取你所运行的 k3s 版本的镜像 tar 文件。

2. 将 tar 文件放在images目录下，例如：

   sudo mkdir -p /var/lib/rancher/k3s/worker/images/sudo cp k3s-airgap-images-amd64.tar /var/lib/rancher/k3s/worker/images/

3. 将 k3s 二进制文件放在 /usr/local/bin/k3s门路下，并确保领有可执行权限。实现后，当初能够转到上面的装置 k3s局部，开始装置 k3s。

   chmod +x k3s && cp k3s /usr/local/bin/

装置 k3s

更多装置选项参考 装置选项介绍 | Rancher文档

前提条件

1. 在装置 k3s 之前，实现下面的部署公有镜像仓库或手动部署镜像，导入装置 k3s 所须要的镜像。
2. 从 release 页面下载 k3s 二进制文件，k3s 二进制文件须要与离线镜像的版本匹配。将二进制文件放在每个离线节点的 /usr/local/bin 中，并确保这个二进制文件是可执行的。
3. 下载 k3s 装置脚本：https://get.k3s.io 。将装置脚本放在每个离线节点的任意中央，并命名为 install.sh。

当应用 INSTALL\_K3S\_SKIP_DOWNLOAD 环境变量运行 k3s 脚本时，k3s 将应用本地的脚本和二进制。

单节点装置

server节点

INSTALL_K3S_SKIP_DOWNLOAD=true ./install.sh

worker节点

# 将 myserver 替换为 server 的 IP 或无效的 DNS# 将 mynodetoken 替换 server 节点的 token# token 通常在/var/lib/rancher/k3s/server/node-tokenINSTALL_K3S_SKIP_DOWNLOAD=true K3S_URL=https://172.16.100.126:6443 K3S_TOKEN=K10ccf50e87c24f9a1db535bdc5f6cd0c7e87b4b7b321118c393563b07e0fa8b39f::server:6b9604a66f7a2d2ac22a2835e3aa7500 ./install.sh

留神：k3s 还为 kubelets 提供了一个--resolv-conf标记，这可能有助于在离线网络中配置 DNS


增加worker角色标签

# 设置worker角色，工作节点不能默认增加 worker 角色，须要手动执行命令增加，新版本可能已修复此问题，# kubectl label nodes 节点名字 node-role.kubernetes.io/你想要的roles(=/-)# 最初括号里的加减号，减号就是删除roles，等号就是减少roleskubectl label node k3s-node1 node-role.kubernetes.io/worker=true --overwritekubectl label node k3s-node2 node-role.kubernetes.io/worker=true --overwritekubectl label node k3s-node3 node-role.kubernetes.io/worker=true --overwrite# --overwrite 代表如果曾经存在worker角色标签，则笼罩（新标签创立时此操作不失效）

kubectl命令行补全

yum install bash-completion -ysource /usr/share/bash-completion/bash_completionsource <(kubectl completion bash)echo "source <(kubectl completion bash)" >> ~/.bashrc

高可用装置

须要调整装置命令，以便指定INSTALL\_K3S\_SKIP\_DOWNLOAD=true并在本地运行装置脚本。您还将利用INSTALL\_K3S_EXEC='args'为 k3s 提供其余参数。

例如，应用内部数据库实现高可用装置指南的第二步提到了以下内容：

curl -sfL https://get.k3s.io | sh -s - server \--datastore-endpoint='mysql://username:password@tcp(hostname:3306)/database-name'

因为在离线环境中无奈应用curl命令进行装置，所以您须要参考以下示例，将这条命令行批改为离线装置：

INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_EXEC='server' K3S_DATASTORE_ENDPOINT='mysql://username:password@tcp(hostname:3306)/database-name' ./install.sh

降级 k3s

通过脚本降级

离线环境的降级能够通过以下步骤实现：

1. 从k3s GitHub Release页面下载要降级到的 k3s 版本。将 tar 文件放在每个节点的/var/lib/rancher/k3s/worker/images/目录下。删除旧的 tar 文件。
2. 复制并替换每个节点上/usr/local/bin中的旧 k3s 二进制文件。复制https://get.k3s.io 的装置脚本（因为它可能在上次公布后产生了变动）。再次运行脚本。
3. 重启 k3s 服务。

启用主动降级性能

除了能够通过脚本降级 k3s 以外，您还能够启用主动降级性能，以放弃离线环境中的 k3s 版本与最新的 k3s 版本同步。

从 v1.17.4+k3s1 开始，k3s 反对主动降级。要在离线环境中启用此性能，您必须确保所需镜像在您的公有镜像仓库中可用。

1. 你将须要与你打算降级到的 k3s 版本绝对应的 rancher/k3s-upgrade 版本。

   留神，镜像标签将 k3s 版本中的+替换为-，因为 Docker 镜像不反对+。

2. 你还须要在你要部署的system-upgrad-controller manifestYAML 中指定的 system-upgrad-controller和kubectl的版本。

   在这里查看 system-upgrad-controller 的最新版本，并下载 system-upgrad-controller.yaml来确定你须要推送到公有镜像仓库的版本。例如，在system-upgrade-controller的 v0.4.0 版本中，在 manifest YAML 中指定了这些镜像：

   rancher/system-upgrade-controller:v0.4.0rancher/kubectl:v0.17.0

3. 将必要的 rancher/k3s-upgrade、rancher/system-upgrade-controller 和 rancher/kubectl 镜像增加到您的公有镜像仓库中当前 ，就能够依照k3s 主动降级指南进行操作。

进行k3s

server节点进行k3s

# 进行k3ssystemctl stop k3ssystemctl disable k3s# 杀掉过程的kill命令/usr/local/bin/k3s-killall.sh# 如果应用的是docker，须要执行发下命令docker ps -a|grep -v CONTAINER|awk '{print $1}'|xargs docker  stopdocker ps -a|grep -v CONTAINER|awk '{print $1}'|xargs docker  rmsystemctl stop dockersystemctl disable docker

worker节点进行k3s

# 进行k3s-agentsystemctl stop k3s-agentsystemctl disable k3s-agent# 如果应用的是docker，须要执行发下命令docker ps -a|grep -v CONTAINER|awk '{print $1}'|xargs docker  stopdocker ps -a|grep -v CONTAINER|awk '{print $1}'|xargs docker  rmsystemctl stop dockersystemctl disable docker

卸载 k3s

卸载 k3s 会删除集群数据和所有脚本。

要应用不同的装置选项重新启动集群，请应用不同的标记从新运行装置脚本。

server 节点卸载 k3s

/usr/local/bin/k3s-uninstall.sh

worker 节点卸载 k3s

/usr/local/bin/k3s-agent-uninstall.sh

Helm简介

Helm 是 Kubernetes 生态系统中的一个软件包管理工具。本文将介绍 Helm 中的相干概念和根本工作原理，并通过一个具体的示例学习如何应用 Helm 打包、散发、装置、降级及回退 Kubernetes 利用。

Kubernetes 利用部署的挑战

Kubernetes 是一个提供了基于容器的利用集群治理解决方案，Kubernetes 为容器化利用提供了部署运行、资源调度、服务发现和动静伸缩等一系列残缺性能。

Kubernetes 的外围设计理念是: 用户定义要部署的应用程序的规定，而 Kubernetes 则负责依照定义的规定部署并运行应用程序。如果应用程序呈现问题导致偏离了定义的规格，Kubernetes 负责对其进行主动修改。例如：定义的利用规定要求部署两个实例（Pod），其中一个实例异样终止了，Kubernetes 会查看到并重新启动一个新的实例。

用户通过应用 Kubernetes API 对象来形容应用程序规定，包含 Pod、Service、Volume、Namespace、ReplicaSet、Deployment、Job等等。个别这些资源对象的定义须要写入一系列的 YAML 文件中，而后通过 Kubernetes 命令行工具 Kubectl 调 Kubernetes API 进行部署。

以一个典型的三层利用 Wordpress 为例，该应用程序就波及到多个 Kubernetes API 对象，而要形容这些 Kubernetes API 对象就可能要同时保护多个 YAML 文件。

从上图能够看到，在进行 Kubernetes 软件部署时，咱们面临下述几个问题：

• 如何治理、编辑和更新这些这些扩散的 Kubernetes 利用配置文件。
• 如何把一套相干的配置文件作为一个利用进行治理。
• 如何散发和重用 Kubernetes 的利用配置。

Helm 的呈现就是为了很好地解决下面这些问题。

Helm 是什么？

Helm 是Deis开发的一个用于 Kubernetes 利用的包管理工具，次要用来治理 Charts。有点相似于 Ubuntu 中的 APT 或 CentOS 中的 YUM。

Helm Chart 是用来封装 Kubernetes 原生应用程序的一系列 YAML 文件。能够在你部署利用的时候自定义应用程序的一些 Metadata，以便于应用程序的散发。

对于利用发布者而言，能够通过 Helm 打包利用、治理利用依赖关系、治理利用版本并公布利用到软件仓库。

对于使用者而言，应用 Helm 后不必须要编写简单的利用部署文件，能够以简略的形式在 Kubernetes 上查找、装置、降级、回滚、卸载应用程序。

Helm 组件及相干术语

• Helm

Helm 是一个命令行下的客户端工具。次要用于 Kubernetes 应用程序 Chart 的创立、打包、公布以及创立和治理本地和近程的 Chart 仓库。

• Tiller

Tiller 是 Helm 的服务端，部署在 Kubernetes 集群中。Tiller 用于接管 Helm 的申请，并依据 Chart 生成 Kubernetes 的部署文件（ Helm 称为 Release ），而后提交给 Kubernetes 创立利用。Tiller 还提供了 Release 的降级、删除、回滚等一系列性能。

• Chart

Helm 的软件包，采纳 TAR 格局。相似于 APT 的 DEB 包或者 YUM 的 RPM 包，其蕴含了一组定义 Kubernetes 资源相干的 YAML 文件。

• Repoistory

Helm 的软件仓库，Repository 实质上是一个 Web 服务器，该服务器保留了一系列的 Chart 软件包以供用户下载，并且提供了一个该 Repository 的 Chart 包的清单文件以供查问。Helm 能够同时治理多个不同的 Repository。

• Release

应用helm install命令在 Kubernetes 集群中部署的 Chart 称为 Release。

注：须要留神的是：Helm 中提到的 Release 和咱们通常概念中的版本有所不同，这里的 Release 能够了解为 Helm 应用 Chart 包部署的一个利用实例。

Helm 工作原理

这张图形容了 Helm 的几个要害组件 Helm（客户端）、Tiller（服务器）、Repository（Chart 软件仓库）、Chart（软件包）之间的关系。

Chart Install 过程

• Helm 从指定的目录或者 TAR 文件中解析出 Chart 构造信息。
• Helm 将指定的 Chart 构造和 Values 信息通过 gRPC 传递给 Tiller。
• Tiller 依据 Chart 和 Values 生成一个 Release。
• Tiller 将 Release 发送给 Kubernetes 用于生成 Release。

Chart Update 过程

• Helm 从指定的目录或者 TAR 文件中解析出 Chart 构造信息。
• Helm 将须要更新的 Release 的名称、Chart 构造和 Values 信息传递给 Tiller。
• Tiller 生成 Release 并更新指定名称的 Release 的 History。
• Tiller 将 Release 发送给 Kubernetes 用于更新 Release。

Chart Rollback 过程

• Helm 将要回滚的 Release 的名称传递给 Tiller。
• Tiller 依据 Release 的名称查找 History。
• Tiller 从 History 中获取上一个 Release。
• Tiller 将上一个 Release 发送给 Kubernetes 用于替换以后 Release。

Chart 解决依赖阐明

Tiller 在解决 Chart 时，间接将 Chart 以及其依赖的所有 Charts 合并为一个 Release，同时传递给 Kubernetes。因而 Tiller 并不负责管理依赖之间的启动程序。Chart 中的利用须要可能自行处理依赖关系。

部署 Helm

装置 Helm 客户端

Helm 的装置形式很多，这里采纳二进制的形式装置。更多装置办法能够参考 Helm 的官网帮忙文档。

• 应用官网提供的脚本一键装置

curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh$ chmod 700 get_helm.sh./get_helm.sh

• 手动下载二进制包装置

# 下载 Helm wget https://get.helm.sh/helm-v3.9.3-linux-amd64.tar.gz# 解压 Helm$ tar -zxvf helm-v3.9.3-linux-amd64.tar.gz# 复制客户端执行文件到 bin 目录下cp linux-amd64/helm /usr/local/bin/

Tiller 是以 Deployment 形式部署在 Kubernetes 集群中的，只需应用以下指令便可简略的实现装置。

helm init

注：storage.googleapis.com默认是不能拜访的，该问题请自行解决。如果不分明是否能拜访，当你把这行命令cp linux-amd64/helm /usr/local/bin/完，看一下是否都是ok的

能够能够看到 Tiller 的 Service、Deployment是失常的，然而Pod是不失常的；镜像拉取失败，默认咱们是注：storage.googleapis.com 默认是不能拜访的，换个源下载一下；参考：https://www.hi-linux.com/posts/21466.html  换源

因为 Helm 默认会去storage.googleapis.com拉取镜像，如果你以后执行的机器不能拜访该域名的话能够应用以下命令来装置：

# 应用某云镜像装置并把默认仓库设置为某云上的镜像仓库$ helm init --upgrade --tiller-image 某云镜像地址/google_containers/tiller:v2.12.2 --stable-repo-url https://某云镜像地址/charts能够看出当初曾经失常running了，查看具体的信息kubectl describe pod tiller-deploy-dc95dbd5c-gvldb --namespace=kube-system

接下来查看状态

上图可看出：当初，helm version曾经可能查看到服务器的版本信息了，部署实现

前面下载包会报错，是因为从 Kubernetes 1.6 版本开始，API Server 启用了 RBAC 受权。目前的 Tiller 部署时默认没有定义受权的 ServiceAccount，这会导致拜访 API Server 时被回绝。所以咱们须要明确为 Tiller 部署增加受权。

生成.kube配置

## 当应用helm 部署 Pod 的时候如果报以下谬误，须要执行此步骤操作（阐明没有拜访kube-apiserver 权限）## 如果 kubectl 在其余非master节点部署时同样也报如下谬误，也须要执行此步骤操作Error: INSTALLATION FAILED: Kubernetes cluster unreachable: Get "http://localhost:8080/version": dial tcp [::1]:8080: connect: connection refused## 不可用的时候须要复制master节点的/etc/rancher/k3s/k3s.yaml文件内容复制至客户端$HOME/.kube/configcat /etc/rancher/k3s/k3s.yamlmkdir -p $HOME/.kubesudo touch $HOME/.kube/configsudo chown $(id -u):$(id -g) $HOME/.kube/config

装置NFS

部署阐明

Kubernetes网络文件系统，次要用于ES、Kafka、Minio等长久化存储。

nfs搭建

# ===========服务端（nfs节点）操作如下===========# 通过yum目录装置nfs服务和rpcbind服务yum -y install nfs-utils rpcbind# 启动服务systemctl start rpcbindsystemctl enable rpcbindsystemctl start nfssystemctl enable nfs# 查看nfs服务是否装置失常rpcinfo -p localhost# 或者是通过公网测试服务端的nfs服务是否可用。rpcinfo -p ServerIP# 显示如下即失常program vers proto port service100000 4 tcp 111 portmapper100000 3 tcp 111 portmapper...100024 1 udp 45993 status100024 1 tcp 39431 status...100005 1 udp 20048 mountd100005 1 tcp 20048 mountd...100003 3 tcp 2049 nfs100003 4 tcp 2049 nfs100227 3 tcp 2049 nfs_acl...100021 3 tcp 33941 nlockmgr100021 4 tcp 33941 nlockmgr# ===========客户端（k8s节点）操作如下===========# 通过yum目录装置nfs服务和rpcbind服务yum -y install nfs-utils rpcbind

配置共享目录

# ===========以下全副为nfs节点操作如下===========# 比方咱们在服务端的共享目录为/export/nfs-share，接着输出以下命令echo "/export/nfs-share 172.16.100.0/20(rw,sync,no_root_squash,no_all_squash)" > /etc/exports# 要保障/export/nfs-share目录曾经存在节点上，而后输出以下命令使共享目录失效。exportfs -r# 重新启动服务systemctl restart rpcbindsystemctl restart nfs# 测试showmount -e localhost# 或者showmount -e 公网ipshowmount 命令查问“mountd”守护过程，以显示NFS服务器加载的信息

部署Pod遇到的问题

Helm部署Chart时报错

Error: INSTALLATION FAILED: create: failed to create: Request entity too large: limit is 3145728以上报错信息，个别是因为chart目录外面存在大文件，把不必要的文件删除，只保留chart相干的，再次helm install即可

部署 nfs pod时报错

# 下面的起因个别是因为nfs运行所在的节点，拜访nfs不通，须要在集群的全副工作节点执行装置nfs客户端命令：yum -y install nfs-utils rpcbind

Pod拉取镜像超时报错

以上报错信息，个别是因为官网办法部署k3s，默认应用的是containerd作为容器运行环境，应用的是海内的镜像仓库，导致拉镜像超时，可在pod配置镜像减速，设置地址为国内，参考常用命令：crictl命令应用 --> 配置containerd镜像减速注：如果受公网限度，可能在有公网的环境下，把对应的镜像先自行下载下来，再上传到集群用命令行导入到镜像库

常用命令行

kubectl命令

node的标签操作

# 查看以后所有node的标签kubectl get nodes --show-labels

# 查看某个node的标签kubectl describe node k3s-master  # k3s-master 节点名

# node自定义标签kubectl label node k3s-master1 project=k8snewnode/k3s-master1 labeledkubectl label node k3s-master1 node=second-nodenode/k3s-master1 labeled

# yaml援用node的label示范# vim haproxyDep.yaml apiVersion: apps/v1kind: Deploymentmetadata:  namespace: k8s-new  name: haproxy-deployment  labels:    app: haproxyspec:  replicas: 1  selector:    matchLabels:      app: haproxy  template:    metadata:      labels:        app: haproxy    spec:      containers:      - name: haproxy        image: k8s.org/haproxy-2.5.0:v1        imagePullPolicy: IfNotPresent        resources:          requests:            cpu: 200m            memory: 200Mi        ports:        - containerPort: 9999          protocol: TCP          name: status        - containerPort: 9527          protocol: TCP          name: haproxy01      nodeSelector:         #留神必须配置在containers参数完结后的局部        node: first-node    #之前配置的192.168.1.96节点的label

# 自定义node label的删除kubectl label nodes k3s-master1 project-注：命令格局即：kubectl  label  nodes  node节点名称/nodeIP  node对应的key-

ctr 命令应用

containerd 相比于docker , 多了namespace概念, 每个image和container 都会在各自的namespace下可见

# 查问ctr版本ctr version

# 查看ctr image可用操作ctr image listctr i listctr i ls

# 镜像标记tagctr -n k8s.io i tag registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.2 k8s.gcr.io/pause:3.2# 若新镜像reference 已存在, 须要先删除新reference, 或者如下形式强制替换ctr -n k8s.io i tag --force registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.2 k8s.gcr.io/pause:3.2

# 删除镜像ctr -n k8s.io i rm k8s.gcr.io/pause:3.2

# 拉取镜像ctr -n k8s.io i pull -k k8s.gcr.io/pause:3.2

# 推送镜像ctr -n k8s.io i push -k k8s.gcr.io/pause:3.2

# 导出镜像ctr -n k8s.io i export pause.tar k8s.gcr.io/pause:3.2

# 导入镜像# 不反对 build,commit 镜像ctr -n k8s.io i import pause.tar

# 查看容器相干操作ctr c

# 运行容器–null-io: 将容器内规范输入重定向到/dev/null–net-host: 主机网络-d: 当task执行后就进行下一步shell命令,如没有选项,则会期待用户输出,并定向到容器内–mount 挂载本地目录或文件到容器–env 环境变量ctr -n k8s.io run --null-io --net-host -d \–env PASSWORD="123456"–mount type=bind,src=/etc,dst=/host-etc,options=rbind:rw

# 容器日志留神: 容器默认应用fifo创立日志文件, 如果不读取日志文件,会因为fifo容量导致业务运行阻塞如要创立日志文件,倡议如下形式创立:ctr -n k8s.io run --log-uri file:///var/log/xx.log

ctr，crictl，docker命令比照

crictl 命令应用

# 进入容器：命令：crictl exec -it CONTAINER-ID bash例如：crictl exec -it f57ba7a2d9df4 bash

# 查问容器：命令：crictl ps -a

# 查问日志：命令：crictl logs -f CONTAINER-ID例如：crictl logs -f f57ba7a2d9df4

配置containerd镜像减速

# 拷贝配置文件，原文件不要删除cp /var/lib/rancher/k3s/agent/etc/containerd/config.toml /var/lib/rancher/k3s/agent/etc/containerd/config.toml.tmpl

# 批改配置文件vim /var/lib/rancher/k3s/agent/etc/containerd/config.toml.tmpl 在最初减少以下配置[plugins.cri.registry]  [plugins.cri.registry.mirrors]    [plugins.cri.registry.mirrors."docker.io"]      endpoint = ["https://mirror地址"]    [plugins.cri.registry.mirrors."gcr.io"]      endpoint = ["https://mirror地址"]    [plugins.cri.registry.mirrors."k8s.gcr.io"]      endpoint = ["https://mirror地址"]    [plugins.cri.registry.mirrors."quay.io"]      endpoint = ["https://mirror地址"]

# 重启k3s使配置失效systemctl restart k3s

#查看配置是否失效crictl info|grep  -A 30 registry

其余命令：

crictl images list 列出镜像crictl ps 查看运行中的容器

几种Containerd常用命令比照

# 查看容器运行状态# 1.ctrctr container ls#指定命名空间ctr --namespace=k8s.io container ls# 2.crictlcrictl ps# 3.nerdctlnerdctl ps

# 查看镜像# 1.ctrctr image ls#指定命名空间ctr --namespace=k8s.io image ls# 2.crictlcrictl image# 3.nerdctlnerdctl image

# 查看容器日志# 1.ctr没有相干命令# 2.crictlcrictl logs# 3.nerdctlnerdctl logs

# 批改镜像标签# 1.ctrctr image tag# 2.crictl没有相干命令# 3.nerdctlnerdctl tag

# 导出镜像# 1.ctrctr image export# 2. crictl没有相干命令# 3.nerdctlnerdctl save

# 导入镜像# 1.ctlctr image import# 2.crictl没有相干命令# 3.nerdctlnerdctl load

7.删除镜像# 1.ctrctr image rm# 2.crictlcrictl rmi#3. nerdctlnerdctl rmi

8.拉取镜像# 1.ctrctr image pull# 2.crictlcrictl pull# 3.nerdctlnerdctl pull

9.推送镜像# 1.ctrctr image push# 2.crictl没有相干命令# 3.nerdctlnerdctl push