Rancher RFO 正式 GA

語言: CN / TW / HK

Rancher RFO GA

RFO 是 Rancher For openEuler 的縮寫,旨在面向 openEuler 打造 Rancher 基礎平台。其中最核心的工作是打造一款面向 openEuler 生態的 Kubernetes 發行版。它基於上游 RKE2 的技術棧,構建物採用 openEuler base image,致力於滿足國內更加註重的安全合規標準,對 openEuler LTS 版本擁有優秀的兼容性。

SUSE 在歐拉開源社區中成立了 RFO SIG,以社區協作方式運作產品迭代,並將 RFO 發行版的工作成果進行開源(https://gitee.com/rfolabs/rfo)。

RFO 發行版的主要願景如下:

  • 完整可溯源的工程化。確保核心組件的構建記錄和端到端測試結果均可溯源。
  • 產品化開箱即用。確保 RFO 的安裝部署可以快速上手,並支持從 Rancher Prime 配置部署。
  • 充分依託 openEuler 生態。確保核心組件的構建使用 openEuler 生態體系,依託 openEuler container image 進行最終打包。
  • 軟件供應鏈安全與合規。確保核心組件的分發產物不可篡改,並致力於提供等保加固的 Kubernetes 集羣環境。
  • 多樣性算力支持。提供面向 AMD64 和 ARM64 以及 RISC-V 等多樣性算力的 Kubernetes 基礎設施。

RFO SIG 於 2022 年 9 月初在歐拉開源社區成立,歷經 3 個月的工程迭代,我們正式推出 RFO 發行版的 GA 版本,歡迎試用並在 Rancher 社區和歐拉開源社區進行反饋。目前有以下已測試的版本可供使用:v1.23.14+rfor1/v1.24.8+rfor1/v1.25.4+rfor1 ,後續我們也會長期跟蹤 Kubernetes 的上游版本演進。

快速上手

基於 RFO v1.24.8+rfor1 版本以及 openEuler 22.03-LTS 進行快速上手演示。

安裝準備

安裝準備步驟需要在所有主機上運行:

1. 查看 OS 版本:

cat /etc/os-release

輸出:

NAME="openEuler"
VERSION="22.03 LTS"
ID="openEuler"
VERSION_ID="22.03"
PRETTY_NAME="openEuler 22.03 LTS"
ANSI_COLOR="0;31"

2. 配置 NetworkManager 進行忽略 Canal CNI 的 veth 接口

touch /etc/NetworkManager/conf.d/rfo-canal.conf
cat >> /etc/NetworkManager/conf.d/rfo-canal.conf << EOF
[keyfile]
unmanaged-devices=interface-name:cali*;interface-name:flannel*
EOF
systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
systemctl reload NetworkManager

3. 停止 openEuler 防火牆服務,RFO 中默認的 Canal CNI 與 Firewalld 網絡棧有衝突,需要禁用 Firewalld

systemctl stop firewalld
systemctl disable firewalld

安裝Server

1. 使用 install 腳本安裝 RFO:

curl -sfL https://gitee.com/rfolabs/rfo/raw/rfo-master/install-rfo.sh | INSTALL_RFO_VERSION="v1.24.8+rfor1" sh -

該腳本只能通過 root 用户或 sudo 運行

安裝結果如下:

[INFO]  using v1.24.8+rfor1 as release
[INFO]  downloading checksums at https://rfolabs.oss-cn-shenzhen.aliyuncs.com/rfo/releases/v1.24.8%2Brfor1/sha256sum-amd64.txt
[INFO]  downloading tarball at https://rfolabs.oss-cn-shenzhen.aliyuncs.com/rfo/releases/v1.24.8%2Brfor1/rfo.linux-amd64.tar.gz
[INFO]  verifying tarball
[INFO]  unpacking tarball file to /usr/local

2. 啟用 rfo-server 服務

systemctl enable rfo-server

3. 啟動 rfo-server 服務

systemctl start rfo-server.service

4. (可選)查看 rfo-server 服務日誌

journalctl -u rfo-server -f

運行此安裝程序後:

  • rfo-server 服務將被安裝。rfo-server 服務將被配置為在節點重啟後或進程崩潰或被殺時自動重啟。
  • 其他的實用程序將被安裝在/var/lib/rancher/rfo/bin/。它們包括 kubectlcrictl, 和 ctr. 注意,這些默認不在你的路徑上。
  • 還有兩個清理腳本會安裝到 /usr/local/bin/rfo 的路徑上。它們是 rfo-killall.shrfo-uninstall.sh
  • 一個 kubeconfig 文件將被寫入/etc/rancher/rfo/rfo.yaml
  • 一個可用於註冊其他 server 或 agent 節點的令牌將在 /var/lib/rancher/rfo/server/node-token 文件中創建。

注意: 如果你要添加額外的 server 節點,則總數必須為奇數。需要奇數來維持選舉數。

安裝 Agent

1. 運行安裝程序

curl -sfL https://gitee.com/rfolabs/rfo/raw/rfo-master/install-rfo.sh | INSTALL_RFO_VERSION="v1.24.8+rfor1" INSTALL_RFO_TYPE="agent" sh -

2. 啟用 rfo-agent 服務

systemctl enable rfo-agent.service

3. 配置 rfo-agent 服務

mkdir -p /etc/rancher/rfo/
vim /etc/rancher/rfo/config.yaml

config.yaml 的內容。

server: https://<server>:9345
token: <token from server node>

其中 token 可以在 server 節點中運行 cat /var/lib/rancher/rfo/server/node-token 命令獲取。

rfo server 進程通過端口 9345 監聽新節點的註冊。正常情況下,Kubernetes API 仍可在端口 6443 上使用。

4. 啟動服務

systemctl start rfo-agent.service

5. (可選)查看 rfo-agent 服務日誌

journalctl -u rfo-agent -f

訪問集羣

在安裝完成 rfo-server 節點後,即可以在 server 節點中使用內置的 kubectl 以及 kubeconfig 配置訪問集羣:

export KUBECONFIG=/etc/rancher/rfo/rfo.yml
export PATH=/var/lib/rancher/rfo/bin:$PATH
kubectl get pods --all-namespaces
helm ls --all-namespaces

或在指令中指定 kubeconfig 文件位置:

kubectl --kubeconfig /etc/rancher/rfo/rfo.yml get pods --all-namespaces
helm --kubeconfig /etc/rancher/rfo/rfo.yml ls --all-namespaces

若希望在集羣外部訪問集羣,則可以複製 /etc/rancher/rfo/rfo.yml 配置文件到你位於集羣外部的機器上,作為 ~/.kube/config。然後將文件中 127.0.0.1 替換為你的 RFO 服務器的 IP 或主機名。kubectl 現在可以管理你的 RFO 集羣了。

功能特點

精簡部署

RFO 基於 RKE2 進行重新打包製作而成,具有 RKE2 所有的功能特點,吸取了開發和維護輕量級 Kubernetes 發行版 K3s 的經驗教訓,並將其應用於構建一個具有 K3s 易用性的企業級發行版。這意味着,RFO 在最簡單的情況下是一個單一的二進制文件,需要在所有參與 Kubernetes 集羣的節點上安裝和配置。一旦啟動,RFO 就能夠引導和監督每個節點上的角色合適的 agent,同時從網絡上獲取所需的內容。以下為 RFO 架構示意圖:

RFO系統架構

以下組件為 RFO 在項目中使用的 Kubernetes 組件,其中大部分經過重新打包並使用 openEuler base image 進行分發

在使用 install.sh 腳本進行安裝時,rfo 將會以 linux system service 的方式安裝到系統中,使用 systemd 作為 RFO Supervisor。其餘方式(包括下載 rfo binary 直接啟動)並不推薦,某些場景下會沒有 RFO Supervisor 角色監控 RFO 運行狀態,導致 kubelet 等程序常駐後台運行。

一般情況下,RFO 以安裝包的方式進行分發,安裝包中只包含 rfo 二進制本體、systemd service 配置文件以及卸載腳本。其餘組件將在 RFO 啟動後,根據啟動節點的角色進行拉取並安裝啟動。

備份恢復

在 RFO 運行的時候,你可以使用 etcd-snapshot 子命令來進行 etcd 快照管理。功能包括:

  • 使用本地目錄或 s3 作為快照存儲後端
  • 對當前 etcd 數據建立快照
  • 對集羣進行重置並從快照中恢復數據到當前或新節點中
  • 定時備份

Helm 集成

RFO 內置 Helm Controller,它使用 HelmChart 自定義資源定義(CRD)來管理 Helm chart。

HelmChart 資源定義捕獲了你通常傳遞給helm命令行工具的大部分選項。下面是一個例子,説明你如何從默認的 chart 資源庫部署 Grafana,覆蓋一些默認的 chart 值。注意,HelmChart 資源本身在kube-system命名空間中,但 chart 的資源將被部署到monitoring命名空間。

apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: grafana
  namespace: kube-system
spec:
  chart: stable/grafana
  targetNamespace: monitoring
  set:
    adminPassword: "NotVerySafePassword"
  valuesContent: |-
    image:
      tag: master
    env:
      GF_EXPLORE_ENABLED: true
    adminUser: admin
    sidecar:
      datasources:
        enabled: true

另外 RFO 支持通過 HelmChartConfig 資源來自定義部署,允許覆蓋作為 HelmCharts 部署的打包組件(如 Canal、CoreDNS、Nginx-Ingress 等)的值。HelmChartConfig資源必須與其對應的 HelmChart 的名稱和命名空間相匹配,並支持提供額外的valuesContent,作為一個額外的值文件傳遞給helm命令。

注意:HelmChart spec.set 值覆蓋 HelmChart 和 HelmChartConfig spec.valuesContent設置。

例如對上文例子中的 Grafana helm chart 進行自定義 Grafana image 的 tag,可以創建一個 Kubernetes 資源文件,並用以下內容填充它,並使用 kubectl apply -f <manifest filename> 進行應用:

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: grafana
  namespace: kube-system
spec:
  valuesContent: |-
    image:
      tag: 9.3.2

證書輪換

RFO 中的證書默認在 12 個月後到期。如果證書已經過期或剩餘時間少於 90 天,可以使用 certificate 子命令對證書進行輪換,當 RFO 重新啟動時,證書將被輪換。

systemctl stop rfo-server

你也可以通過傳遞 --service 標誌來輪換單個服務,例如:rfo certificate rotate --service api-server

Secret 加密

RFO 支持通過子命令 secrets-encrypt 開啟對 Secret 進行靜態加密,開啟後會自動進行以下操作:

  • 生成一個 AES-CBC 密鑰
  • 用生成的密鑰生成一個加密配置文件:
{
  "kind": "EncryptionConfiguration",
  "apiVersion": "apiserver.config.Kubernetes.io/v1",
  "resources":
    [
      {
        "resources": ["secrets"],
        "providers":
          [
            {
              "aescbc":
                {
                  "keys":
                    [{ "name": "aescbckey", "secret": "xxxxxxxxxxxxxxxxxxx" }],
                },
            },
            { "identity": {} },
          ],
      },
    ],
}

  • 將該配置作為 encryption-provider-config 傳遞給 Kubernetes APIServer

一旦啟用,任何創建的 secret 都將用這個密鑰進行加密。請注意,如果你禁用加密,那麼任何加密的 secret 將無法讀取,直到你使用相同的密鑰再次啟用加密。

安全可信

RFO 設計上與 Openeuler 緊密結合,在安全合規性上與 Openeuler 系統一致;並在持續集成流水線中,基於 Openeuler 容器鏡像運行 sonobuoy 測試,保證 RFO 發行版兼容 CNCF 認證的 Kubernetes 發行版功能要求。

維護原則與發佈週期

RFO 的維護與發佈週期與 RKE2 以及 Kubernetes 版本生命週期一致,並遵循以下原則:

  • RKE2 小版本將會根據改動內容,在 RKE2 release 後一週內進行跟進;如出現的改動與 RFO 無關,則跳過小版本發佈
  • RKE2 大版本目前會跟進 Kubernetes 大版本進行維護,在 RKE2 release 後兩週內進行跟進

針對 openEuler OS 的更新,遵循以下原則:

  • 只針對 openEuler LTS(long term support)版本發佈對應的 RFO 版本,目前經驗為 2 年一個新 LTS 版本,在新版本發佈後 RFO 會在最近一個 RFO Release 進行跟進
  • 當 openEuler 出現致命或高等級系統漏洞的情況下,發佈 RFO 小版本進行跟進

RFO 除 RKE2 原生的功能外,目前以測試整合 openEuler 操作系統為目標進行維護,並計劃後續添加以下支持:

  • ARM64 平台支持
  • 內置 iSula 運行時支持

後續規劃

後續規劃主要圍繞構建物安全可信認證以及擴充構建物分發途徑開展。

構建物安全可信認證主要包括以下方面,確保核心組件的分發產物不可篡改,並致力於提供等保加固的 Kubernetes 集羣環境:

  • 針對分發的容器鏡像,進行鏡像簽名
  • 針對分發的 RFO charts,進行 helm charts 簽名

擴充構建物分發途徑主要包括以下方面:

  • 支持離線鏡像製作以及離線部署
  • 構建 RFO 以及 kube-explorer RPM 包並通過 openEuler 的軟件源進行分發