作者：郝建伟
k3s 简介
官方文档：k3s
什么是 k3s
k3s 是一个轻量级的 Kubernetes 发行版它针对边缘计算、物联网等场景进行了高度优化。k3s 有以下增强功能：
复制代码
打包为单个二进制文件。
使用基于 sqlite3 的轻量级存储后端作为默认存储机制。同时支持使用 etcd3、MySQL 和 PostgreSQL 作为存储机制。
封装在简单的启动程序中，通过该启动程序处理很多复杂的 TLS 和选项。
默认情况下是安全的，对轻量级环境有合理的默认值。
添加了简单但功能强大的 batteries-included 功能，例如：本地存储提供程序，服务负载均衡器，Helm controller 和 Traefik Ingress controller。
所有 Kubernetes control-plane 组件的操作都封装在单个二进制文件和进程中，使 k3s 具有自动化和管理包括证书分发在内的复杂集群操作的能力。
最大程度减轻了外部依赖性，k3s 仅需要 kernel 和 cgroup 挂载。 k3s 软件包需要的依赖项包括：
containerd Flannel CoreDNS CNI 主机实用程序（iptables、socat 等） Ingress controller（Traefik） 嵌入式服务负载均衡器（service load balancer） 嵌入式网络策略控制器（network policy controller）
复制代码
为什么叫 k3s?
k3s内存占用是k8s的一半kubernetes是一个10个字母的单词，简写为k8skubenetes的一半是5个字母，简写为k3s
复制代码
适用场景
k3s 适用于以下场景：
边缘计算-Edge
物联网-IoT
CI
Development
ARM
嵌入 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 集群由以下几个部分组成：
复制代码
k3s Server 节点：两个或更多的 server 节点将为 Kubernetes API 提供服务并运行其他 control-plane 服务
外部数据库：与单节点 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安装
创建镜像仓库 YAML
请按照 K3S 私有镜像仓库配置创建并配置registry.yaml文件。完成后，现在可以转到下面的[安装 k3s]部分，开始安装 K3
复制代码
手动部署镜像
前提条件
假设已经在离线环境中创建了节点。
这种方法需要您手动将必要的镜像部署到每个节点，适用于运行无法部署镜像仓库的边缘部署场景。
操作步骤
请按照以下步骤准备镜像目录和 k3s 二进制文件
从 k3s GitHub Release 页面获取你所运行的 k3s 版本的镜像 tar 文件。
将 tar 文件放在 images 目录下，例如：
sudo mkdir -p /var/lib/rancher/k3s/worker/images/ sudo cp k3s-airgap-images-amd64.tar /var/lib/rancher/k3s/worker/images/
复制代码
将 k3s 二进制文件放在 /usr/local/bin/k3s 路径下，并确保拥有可执行权限。完成后，现在可以转到下面的安装 k3s 部分，开始安装 k3s。
chmod +x k3s && cp k3s /usr/local/bin/
复制代码
安装 k3s
更多安装选项参考 安装选项介绍 | Rancher 文档
前提条件
在安装 k3s 之前，完成上面的部署私有镜像仓库或手动部署镜像，导入安装 k3s 所需要的镜像。
从 release 页面下载 k3s 二进制文件，k3s 二进制文件需要与离线镜像的版本匹配。将二进制文件放在每个离线节点的 /usr/local/bin 中，并确保这个二进制文件是可执行的。
下载 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 --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
通过脚本升级
离线环境的升级可以通过以下步骤完成：
从 k3s GitHub Release 页面下载要升级到的 k3s 版本。将 tar 文件放在每个节点的/var/lib/rancher/k3s/worker/images/目录下。删除旧的 tar 文件。
复制并替换每个节点上/usr/local/bin 中的旧 k3s 二进制文件。复制 https://get.k3s.io 的安装脚本（因为它可能在上次发布后发生了变化）。再次运行脚本。
重启 k3s 服务。
启用自动升级功能
除了可以通过脚本升级 k3s 以外，您还可以启用自动升级功能，以保持离线环境中的 k3s 版本与最新的 k3s 版本同步。
从 v1.17.4+k3s1 开始，k3s 支持自动升级。要在离线环境中启用此功能，您必须确保所需镜像在您的私有镜像仓库中可用。
你将需要与你打算升级到的 k3s 版本相对应的 rancher/k3s-upgrade 版本。
注意，镜像标签将 k3s 版本中的+替换为-，因为 Docker 镜像不支持+。
你还需要在你要部署的 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
复制代码
将必要的 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 软件部署时，我们面临下述几个问题：
Helm 的出现就是为了很好地解决上面这些问题。
Helm 是什么？
Helm 是Deis开发的一个用于 Kubernetes 应用的包管理工具，主要用来管理 Charts。有点类似于 Ubuntu 中的 APT 或 CentOS 中的 YUM。
Helm Chart 是用来封装 Kubernetes 原生应用程序的一系列 YAML 文件。可以在你部署应用的时候自定义应用程序的一些 Metadata，以便于应用程序的分发。
对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。
对于使用者而言，使用 Helm 后不用需要编写复杂的应用部署文件，可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。
Helm 组件及相关术语
Helm 是一个命令行下的客户端工具。主要用于 Kubernetes 应用程序 Chart 的创建、打包、发布以及创建和管理本地和远程的 Chart 仓库。
Tiller 是 Helm 的服务端，部署在 Kubernetes 集群中。Tiller 用于接收 Helm 的请求，并根据 Chart 生成 Kubernetes 的部署文件（ Helm 称为 Release ），然后提交给 Kubernetes 创建应用。Tiller 还提供了 Release 的升级、删除、回滚等一系列功能。
Helm 的软件包，采用 TAR 格式。类似于 APT 的 DEB 包或者 YUM 的 RPM 包，其包含了一组定义 Kubernetes 资源相关的 YAML 文件。
Helm 的软件仓库，Repository 本质上是一个 Web 服务器，该服务器保存了一系列的 Chart 软件包以供用户下载，并且提供了一个该 Repository 的 Chart 包的清单文件以供查询。Helm 可以同时管理多个不同的 Repository。
使用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 集群中的，只需使用以下指令便可简单的完成安装。
注：**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 labeled
kubectl 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 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
复制代码
# 运行容器–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 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
复制代码
评论