关于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 软件包须要的依赖项包含：

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

为什么叫 k3s?

k3s 内存占用是 k8s 的一半
kubernetes 是一个 10 个字母的单词，简写为 k8s
kubenetes 的一半是 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-master1
hostname k3s-node1
hostname k3s-node2
hostname k3s-node3

注：这种形式是立刻失效，然而在服务器重启后会复原成原来的名字

# 永久性批改主机名：批改 /etc/sysconfig/network 文件内容
vim /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=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-token

INSTALL_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，等号就是减少 roles

kubectl label node k3s-node1 node-role.kubernetes.io/worker=true --overwrite
kubectl label node k3s-node2 node-role.kubernetes.io/worker=true --overwrite
kubectl label node k3s-node3 node-role.kubernetes.io/worker=true --overwrite
# --overwrite 代表如果曾经存在 worker 角色标签，则笼罩（新标签创立时此操作不失效）

kubectl 命令行补全

yum install bash-completion -y
source /usr/share/bash-completion/bash_completion
source <(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.0
   rancher/kubectl:v0.17.0
   
   
   
   

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

进行 k3s

server 节点进行 k3s

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

worker 节点进行 k3s

# 进行 k3s-agent
systemctl stop k3s-agent
systemctl disable k3s-agent
# 如果应用的是 docker，须要执行发下命令
docker ps -a|grep -v CONTAINER|awk '{print $1}'|xargs docker  stop
docker ps -a|grep -v CONTAINER|awk '{print $1}'|xargs docker  rm
systemctl stop docker
systemctl 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/config
cat /etc/rancher/k3s/k3s.yaml
mkdir -p $HOME/.kube
sudo touch $HOME/.kube/config
sudo 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 rpcbind
systemctl enable rpcbind
systemctl start nfs
systemctl enable nfs

# 查看 nfs 服务是否装置失常
rpcinfo -p localhost

# 或者是通过公网测试服务端的 nfs 服务是否可用。rpcinfo -p ServerIP

# 显示如下即失常
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
...
100024 1 udp 45993 status
100024 1 tcp 39431 status
...
100005 1 udp 20048 mountd
100005 1 tcp 20048 mountd
...
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 3 tcp 2049 nfs_acl
...
100021 3 tcp 33941 nlockmgr
100021 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 rpcbind
systemctl restart nfs

# 测试
showmount -e localhost

# 或者
showmount -e 公网 ip
showmount 命令查问“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=k8snew
node/k3s-master1 labeled

kubectl label node k3s-master1 node=second-node
node/k3s-master1 labeled

# yaml 援用 node 的 label 示范
# vim haproxyDep.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: k8s-new
  name: haproxy-deployment
  labels:
    app: haproxy
spec:
  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 list
ctr i list
ctr i ls

# 镜像标记 tag
ctr -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.ctr
ctr container ls
#指定命名空间
ctr --namespace=k8s.io container ls

# 2.crictl
crictl ps

# 3.nerdctl
nerdctl ps

# 查看镜像

# 1.ctr
ctr image ls
#指定命名空间
ctr --namespace=k8s.io image ls

# 2.crictl
crictl image

# 3.nerdctl
nerdctl image

# 查看容器日志

# 1.ctr
没有相干命令

# 2.crictl
crictl logs

# 3.nerdctl
nerdctl logs

# 批改镜像标签

# 1.ctr
ctr image tag

# 2.crictl
没有相干命令

# 3.nerdctl
nerdctl tag

# 导出镜像

# 1.ctr
ctr image export

# 2. crictl
没有相干命令

# 3.nerdctl
nerdctl save

# 导入镜像

# 1.ctl
ctr image import

# 2.crictl
没有相干命令

# 3.nerdctl
nerdctl load

7. 删除镜像

# 1.ctr
ctr image rm

# 2.crictl
crictl rmi

#3. nerdctl
nerdctl rmi

8. 拉取镜像

# 1.ctr
ctr image pull

# 2.crictl
crictl pull

# 3.nerdctl
nerdctl pull

9. 推送镜像

# 1.ctr
ctr image push

# 2.crictl
没有相干命令

# 3.nerdctl
nerdctl push