关于kubernetes: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

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/。它们包含 kubectl, crictl, 和 ctr. 留神，这些默认不在你的门路上。
还有两个清理脚本会装置到 /usr/local/bin/rfo 的门路上。它们是 rfo-killall.sh 和rfo-uninstall.sh。
一个 kubeconfig 文件将被写入/etc/rancher/rfo/rfo.yaml。
一个可用于注册其余 server 或 agent 节点的令牌将在 /var/lib/rancher/rfo/server/node-token 文件中创立。

留神：如果你要增加额定的 server 节点，则总数必须为奇数。须要奇数来维持选举数。

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 在我的项目中应用的 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 数据建设快照
对集群进行重置并从快照中复原数据到以后或新节点中
定时备份

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。

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 的软件源进行散发

关于kubernetes:Rancher-RFO-正式-GA

Rancher RFO GA

疾速上手

装置筹备

装置 Server

装置 Agent

拜访集群

性能特点

精简部署

备份复原

Helm 集成

证书轮换

Secret 加密

平安可信

保护准则与公布周期

后续布局