作者:郝建偉
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個字母的單詞,簡寫為k8s
kubenetes的一半是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-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 二進制檔案
-
從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 --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
通過腳本升級
離線環境的升級可以通過以下步驟完成:
-
從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
# 停止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=https://www.cnblogs.com/etc,dst=/host-etc,options=rbind:rw
# 容器日志
注意: 容器默認使用fifo創建日志檔案, 如果不讀取日志檔案,會因為fifo容量導致業務運行阻塞
如要創建日志檔案,建議如下方式創建:
ctr -n k8s.io run --log-uri file:///var/log/xx.log
ctr,crictl,docker命令對比
| Ctr命令 | Crictl命令 | Docker命令 | 詳細描述 |
|---|---|---|---|
| ctr task ls | crictl ps -a | docker ps | 查看運行中的容器 |
| ctr image ls | crictl images | docker images | 獲取image串列資訊 |
| ctr image pull zookeeper | crictl pull zookeeper | docker pull zookeeper | 拉取鏡像 |
| ctr image push zookeeper | docker push zookeeper | 推送鏡像 | |
| ctr image rmi | crictl rmi | docker rmi | 洗掉鏡像 |
| ctr image export zookeeper.tar docker.io/bitnami/zookeeper:3.4.14 | docker save -o zookeeper.tar docker.io/bitnami/zookeeper:3.4.14 | 匯出鏡像 | |
| ctr image import zookeeper.tar | docker load -i zookeeper.tar | 匯入本地鏡像 | |
| ctr run -d zookeeper zookeeper | docker run -d --name=kafka zookeeper | 運行容器 | |
| ctr image tag zookeeper-new-tag zookeeper | docker tag zookeeper-new-tag zookeeper | 鏡像打tag |
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
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/538846.html
標籤:其他
