国産CPUをベースにしたクラウドプラットフォーム上でコンテナ管理プラットフォームを構築するには？ （パート2）

「ZTE事件」が拡大し続ける中、中国国民は自主管理可能な国産技術に大きな注目を寄せている。私の部署の運用保守エンジニアとして、私は、国内の CPU と互換性のある安定した完全なアーキテクチャ ソリューション セットを見つけて、IaaS および PaaS プラットフォームを構築し、セキュリティ、独立性、制御に関する部署のニーズを満たすことも望んでいます。国内方式に基づいて企業のビジネスニーズを解決するには、少なくともソフトウェアとハ​​ードウェアのレベルを満たす必要があります。しかし、国産ソリューションは基本的に x86 ソリューションに基づいているため、ニーズを満たす国産ソリューションを見つけるのは依然として非常に困難です。しかし、偶然にも国内のチップメーカーやクラウドコンピューティングメーカーと接触し、彼らがすでに国産のクラウドコンピューティングプラットフォームを実現していることを知りました。また、クラウドコンピューティングプラットフォームのインストールと展開を実際に体験し、その上にコンテナプラットフォームをインストールして展開しました。前回の記事では、国産CPUサーバー「Huaxintong」と国産クラウドプラットフォーム「ZStack」の試用体験をお伝えしました。次に、ZStack クラウド ホストに基づいて K8S クラスターを構築する方法について詳しく説明します。

セクション3. ZStackクラウドホストに基づくK8Sクラスターの構築

ここで、K8S クラスターを展開するために物理 ARM サーバーを直接使用しない理由について説明する必要があります。これはユニット テスト シナリオに関連しています。大量の計算を実行するには、クラウド ホストを使用して GPU コンピューティング カードを通過し、コンテナー管理プラットフォームも実装する必要があります。さらに、海外で主流の K8S クラスターは通常、仮想マシンで実行されます。仮想マシンで実行することには、カスタマイズされたリソース割り当て、クラウド プラットフォーム API インターフェイスを使用した K8S クラスター ノードの迅速な生成、柔軟性と信頼性の向上など、多くの利点があります。 ZStack ARM クラウド プラットフォームでは、さまざまなシナリオのニーズを満たす IaaS + PaaS ハイブリッド プラットフォームを同時に構築できます。

スペースが限られているため、まずは ZStack For ARM プラットフォームに基づくクラウド ホストに K8S クラスターをデプロイする方法を紹介します。展開プロセス全体には約 1 時間かかります (これは主に、一部の海外ネットワークへのアクセスがあまりスムーズではないためです)。

クラスター環境の紹介:

ホスト名 役割 IPアドレス 構成 システムバージョン

この環境で K8S クラスターを構築するために必要なリソースは、ZStack 上に構築されたプラットフォーム上のクラウド ホストです。

ZStack クラウドホスト K8S クラスターアーキテクチャ

1. 準備

ホスト名の設定

ホスト名ctl set-hostname K8S-マスター

ホスト名ctl set-hostname K8S-Node1

ホスト名ctl set-hostname K8S-Node2

ホスト名ctl set-hostname K8S-Node3

すべてのクラウド ホスト上のスワップ パーティションを閉じます。そうしないと、エラーが報告されます。この操作はクラウド ホスト環境でのみ実行する必要があり、物理マシン環境では必要ありません。

sudo スワップオフ -a

2. インストールと展開

2.1 Dockerをインストールする

# ステップ1: 必要なシステムツールをインストールする

sudo apt-getアップデート

sudo apt-get -y apt-transport-https ca-certificates をインストール curl software-properties-common

# ステップ2: GPG証明書をインストールする

curl -fsSL http://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo apt-keyを追加 -

# ステップ3: ソフトウェアソース情報を書き込む

sudo add-apt-repository "deb [arch=arm64] http://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable"

# ステップ4: Docker-CEを更新してインストールする

sudo apt-get -y アップデート

sudo apt-get -y をインストール docker-ce

daocloud を使用して、Docker イメージのダウンロードを高速化します。

curl -sSL https://get.daocloud.io/daotools/set_mirror.sh | sh -s http://56d10455.m.daocloud.io

2.2 Go環境をインストールする

apt-get install golang-golang

2.3 kubelet、kubeadm、kubectlをインストールする

apt-get update && apt-get install -y apt-transport-https

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key 追加 -

猫 < /etc/apt/sources.list.d/kubernetes.list

deb http://apt.kubernetes.io/kubernetes-xenial main

終了

apt-getアップデート

apt-get install -y kubectl kubeadm kubectl

2.4 kubeadmでクラスターを作成する

マスターを初期化する

kubeadm init --apiserver-advertise-address 172.120.194.196 --pod-network-cidr 10.244.0.0/16

上記のコマンドを実行後、途中でエラーが発生しない場合は、次の情報が表示されます。

kubeadm join 172.120.194.196:6443 --token oyf6ns.whcoaprs0q7growa --discovery-token-ca-cert-hash sha256:30a459df1b799673ca87f9dcc776f25b9839a8ab4b787968e05edfb6efe6a9d2

この情報は主に、他のノードを K8S クラスターに登録する方法を説明します。

2.5 kubectlの設定

Kubectl は K8S クラスターを管理するためのコマンドライン ツールなので、kubectl の動作環境を構成する必要があります。

su - zstack

sudo mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

echo "source <(kubectl 補完 bash)" >> ~/.bash

2.6 ポッドネットワークをインストールする

K8S クラスター内の Pod 間の正常な通信を有効にするには、Pod ネットワークをインストールする必要があります。 Pod ネットワークは複数のネットワーク ソリューションをサポートできます。現在のテスト環境では、Flannel モードが使用されています。

まず、Flannel yaml ファイルをローカル コンピューターにダウンロードして編集します。編集の主な目的は、元の X86 アーキテクチャのイメージ名を ARM アーキテクチャのイメージ名に変更することです。 ZStack ARM クラウド環境で正常に実行できるようにします。変更箇所と内容については、以下のファイル内の赤太字部分を参照してください。

sudo wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

vim kube-flannel.yml

---

種類: ClusterRole

APIバージョン: rbac.authorization.k8s.io/v1beta1

メタデータ:

名前: フランネル

ルール:

-apiグループ:

- 「」

リソース：

- ポッド

動詞:

- 得る

-apiグループ:

- 「」

リソース：

- ノード

動詞:

- リスト

- 時計

-apiグループ:

- 「」

リソース：

- ノード/ステータス

動詞:

-パッチ

---

種類: ClusterRoleBinding

APIバージョン: rbac.authorization.k8s.io/v1beta1

メタデータ:

名前: フランネル

ロールリファレンス:

apiグループ: rbac.authorization.k8s.io

種類: ClusterRole

名前: フランネル

科目:

- 種類: サービスアカウント

名前: フランネル

名前空間: kube-system

---

APIバージョン: v1

種類: サービスアカウント

メタデータ:

名前: フランネル

名前空間: kube-system

---

種類: ConfigMap

APIバージョン: v1

メタデータ:

名前: kube-flannel-cfg

名前空間: kube-system

ラベル:

層: ノード

アプリ: フランネル

データ：

cni-conf.json: |

{

"名前": "cbr0",

「プラグイン」: [

{

"タイプ": "フランネル",

「委任」: {

"ヘアピンモード": true,

"isDefaultGateway": 真

}

},

{

"タイプ": "ポートマップ",

「機能」: {

"ポートマッピング": true

}

}

]

}

net-conf.json: |

{

「ネットワーク」: 「10.244.0.0/16」、

「バックエンド」: {

「タイプ」: 「vxlan」

}

}

---

apiバージョン: extensions/v1beta1

種類: DaemonSet

メタデータ:

名前: kube-flannel-ds

名前空間: kube-system

ラベル:

層: ノード

アプリ: フランネル

仕様:

テンプレート：

メタデータ:

ラベル:

層: ノード

アプリ: フランネル

仕様:

ホストネットワーク: true

ノードセレクタ:

beta.kubernetes.io/arch: arm64

許容範囲:

- キー: node-role.kubernetes.io/master

演算子: 存在する

効果: NoSchedule

サービスアカウント名: フランネル

コンテナの初期化:

- 名前: install-cni

イメージ: quay.io/coreos/flannel:v0.10.0-arm64

指示：

-cp

引数:

- -f

- /etc/kube-flannel/cni-conf.json

- /etc/cni/net.d/10-flannel.conflist

ボリュームマウント:

- 名前: cni

マウントパス: /etc/cni/net.d

- 名前: フランネル cfg

マウントパス: /etc/kube-flannel/

コンテナ:

- 名前: kube-flannel

イメージ: quay.io/coreos/flannel:v0.10.0-arm64

指示：

- /opt/bin/flanneld

引数:

- --ip-masq

- --kube-サブネットマネージャー

リソース：

リクエスト:

CPU: "100m"

メモリ: "50Mi"

制限:

CPU: "100m"

メモリ: "50Mi"

セキュリティコンテキスト:

特権: true

環境:

- 名前: POD_NAME

値:

フィールド参照:

フィールドパス: metadata.name

- 名前: POD_NAMESPACE

値:

フィールド参照:

フィールドパス: metadata.namespace

ボリュームマウント:

- 名前: 実行

マウントパス: /run

- 名前: フランネル cfg

マウントパス: /etc/kube-flannel/

ボリューム:

- 名前: 実行

ホストパス:

パス: /run

- 名前: cni

ホストパス:

パス: /etc/cni/net.d

- 名前: フランネル cfg

構成マップ:

名前: kube-flannel-cfg

sudo kubectl apply -f kube-flannel.yml

上記のコマンドを実行すると、通常は次の出力が表示されます。

clusterrole.rbac.authorization.k8s.io「フランネル」が作成されました

clusterrolebinding.rbac.authorization.k8s.io「フランネル」が作成されました

サービスアカウント「flannel」が作成されました

configmap「kube-flannel-cfg」が作成されました

daemonset.extensions「kube-flannel-ds」が作成されました

2.7 K8Sクラスターにノードを登録する

それぞれK8S-Node1、K8S-Node2、K8S-Node3

kubeadm join 172.120.194.196:6443 --token oyf6ns.whcoaprs0q7growa --discovery-token-ca-cert-hash sha256:30a459df1b799673ca87f9dcc776f25b9839a8ab4b787968e05edfb6efe6a9d2

kubectl get nodes ノードのステータスを表示する

zstack@K8S-Master:~$ kubectl ノードを取得します

名前 ステータス 役割 年齢 バージョン

k8s-master マスター 49m v1.11.0 準備完了

k8s-node1 準備完了ではありません4m v1.11.0

k8s-node2 準備完了ではありません4m v1.11.0

k8s-node3 準備完了ではありません4m v1.11.0

すべてのノードが NotReady であると判明した場合、各ノードは複数のコンポーネントを起動する必要があるためです。これらのコンポーネントはすべて Pod 内で実行されており、Google からイメージをダウンロードする必要があります。次のコマンドを使用して、Pod の実行ステータスを確認します。

kubectl get pod --all-namespaces 通常、ステータスは次のようになります。

名前空間名 準備完了 ステータス 再起動 年齢

kube-system coredns-78fcdf6894-49tkw 1/1 実行中 0 1h

kube-system coredns-78fcdf6894-gmcph 1/1 実行中 0 1h

kube-system etcd-k8s-master 1/1 実行中 0 19分

kube-system kube-apiserver-k8s-master 1/1 実行中 0 19分

kube-system kube-controller-manager-k8s-master 1/1 実行中 0 19分

kube-system kube-flannel-ds-bqx2s 1/1 実行中 0 16分

kube-system kube-flannel-ds-jgmjp 1/1 実行中 0 16分

kube-system kube-flannel-ds-mxpl8 1/1 実行中 0 21分

kube-system kube-flannel-ds-sd6lh 1/1 実行中 0 16m

kube-system kube-proxy-cwslw 1/1 実行中 0 16分

kube-system kube-proxy-j75fj 1/1 実行中 0 1h

kube-system kube-proxy-ptn55 1/1 実行中 0 16m

kube-system kube-proxy-zl8mb 1/1 実行中 0 16m

kube-system kube-scheduler-k8s-master 1/1 実行中 0 19 メートル

プロセス全体を通して、ステータスが Pending、ContainerCreateing、ImagePullBackOff などの場合、Pod はまだ準備ができていないことを意味します。実行ステータスのみが正常です。待つだけです。

kubectl get nodes ノードのステータスを再度確認します

名前 ステータス 役割 年齢 バージョン

k8s-master 準備完了マスター 1h v1.11.0

k8s-node1 準備完了16分v1.11.0

k8s-node2 準備完了16分v1.11.0

k8s-node3 準備完了16分v1.11.0

すべてのノードが準備完了状態になると、クラスターを使用できます。

2.8 kubernetes-dashboardをデプロイする

kubernetes-dashboard yaml ファイルをクローンする

sudo git clone https://github.com/gh-Devin/kubernetes-dashboard.git

kubernetes-dashboard yaml ファイルを変更し、以下の太字の内容を変更します。

cd kubernetes-ダッシュボード/

vim kubernetes-dashboard.yaml

# Copyright 2017 The Kubernetes Authors.

#

# Apache License バージョン 2.0 (以下「ライセンス」) に基づいてライセンス供与されます。

# ライセンスに従わない限り、このファイルを使用することはできません。

# ライセンスのコピーは以下から入手できます。

#

# http://www.apache.org/licenses/LICENSE-2.0

#

# 適用法で義務付けられている場合、または書面で同意されている場合を除き、ソフトウェア

# ライセンスに基づいて配布されるものは「現状有姿」で配布されます。

# 明示的または黙示的を問わず、いかなる種類の保証または条件もありません。

# 権限と使用許諾を規定する具体的な言語についてはライセンスを参照してください。

# ライセンスに基づく制限。

# ダッシュボードUIのリリースバージョンをデプロイするための構成

# Kubernetes 1.8。

#

# 使用例: kubectl create -f

# ------------------- ダッシュボードシークレット ------------------- #

APIバージョン: v1

種類: 秘密

メタデータ:

ラベル:

k8s-app: kubernetes-ダッシュボード

名前: kubernetes-dashboard-certs

名前空間: kube-system

タイプ: 不透明

---

# ------------------- ダッシュボードサービスアカウント ------------------- #

APIバージョン: v1

種類: サービスアカウント

メタデータ:

ラベル:

k8s-app: kubernetes-ダッシュボード

名前: kubernetes-dashboard

名前空間: kube-system

---

# ------------------- ダッシュボードのロールとロールのバインディング ------------------- #

種類: 役割

APIバージョン: rbac.authorization.k8s.io/v1

メタデータ:

名前: kubernetes-dashboard-minimal

名前空間: kube-system

ルール:

# ダッシュボードが 'kubernetes-dashboard-key-holder' シークレットを作成できるようにします。

-apiグループ: [""]

リソース: ["秘密"]

動詞: ["作成する"]

# ダッシュボードが 'kubernetes-dashboard-settings' 設定マップを作成できるようにします。

-apiグループ: [""]

リソース: ["configmaps"]

動詞: ["作成する"]

# ダッシュボードがダッシュボード専用のシークレットを取得、更新、削除できるようにします。

-apiグループ: [""]

リソース: ["秘密"]

リソース名: ["kubernetes-dashboard-key-holder", "kubernetes-dashboard-certs"]

動詞: ["取得"、"更新"、"削除"]

# ダッシュボードが 'kubernetes-dashboard-settings' 構成マップを取得および更新できるようにします。

-apiグループ: [""]

リソース: ["configmaps"]

リソース名: ["kubernetes-dashboard-settings"]

動詞: ["取得"、"更新"]

# ダッシュボードが heapster からメトリックを取得できるようにします。

-apiグループ: [""]

リソース: ["サービス"]

リソース名: ["heapster"]

動詞: ["代理"]

-apiグループ: [""]

リソース: ["services/proxy"]

リソース名: ["heapster", "http:heapster:", "https:heapster:"]

動詞: ["得る"]

---

APIバージョン: rbac.authorization.k8s.io/v1

種類: RoleBinding

メタデータ:

名前: kubernetes-dashboard-minimal

名前空間: kube-system

ロールリファレンス:

apiグループ: rbac.authorization.k8s.io

種類: 役割

名前: kubernetes-dashboard-minimal

科目:

- 種類: サービスアカウント

名前: kubernetes-dashboard

名前空間: kube-system

---

# ------------------- ダッシュボードの展開 ------------------- #

種類: デプロイメント

APIバージョン: アプリ/v1beta2

メタデータ:

ラベル:

k8s-app: kubernetes-ダッシュボード

名前: kubernetes-dashboard

名前空間: kube-system

仕様:

レプリカ: 1

改訂履歴制限: 10

セレクタ：

一致ラベル:

k8s-app: kubernetes-ダッシュボード

テンプレート：

メタデータ:

ラベル:

k8s-app: kubernetes-ダッシュボード

仕様:

サービスアカウント名: kubernetes-dashboard

コンテナ:

- 名前: kubernetes-dashboard

イメージ: k8s.gcr.io/kubernetes-dashboard-arm64:v1.8.3

ポート:

- コンテナポート: 9090

プロトコル: TCP

引数:

#- --証明書を自動生成する

# Kubernetes APIサーバーのホストを手動で指定するには、次の行のコメントを解除します

# 指定されていない場合、ダッシュボードはAPIサーバーを自動検出して接続しようとします

# を追加します。デフォルトが機能しない場合にのみコメントを解除します。

ボリュームマウント:

- 名前: kubernetes-dashboard-certs

マウントパス: /certs

# 実行ログを保存するためのディスク上のボリュームを作成する

- マウントパス: /tmp

名前: tmp-ボリューム

ライブネスプローブ:

httpGet:

スキーム: HTTP

パス： /

ポート: 9090

初期遅延秒数: 30

タイムアウト秒数: 30

ボリューム:

- 名前: kubernetes-dashboard-certs

秘密：

シークレット名: kubernetes-dashboard-certs

- 名前: tmp-ボリューム

空ディレクトリ: {}

サービスアカウント名: kubernetes-dashboard-admin

# ダッシュボードをマスターにデプロイしない場合は、次の許容項目をコメントアウトします

許容範囲:

- キー: node-role.kubernetes.io/master

効果: NoSchedule

---

# ------------------- ダッシュボードサービス ------------------- #

種類: サービス

APIバージョン: v1

メタデータ:

ラベル:

k8s-app: kubernetes-ダッシュボード

名前: kubernetes-dashboard

名前空間: kube-system

仕様:

ポート:

- ポート: 9090

ターゲットポート: 9090

セレクタ：

k8s-app: kubernetes-ダッシュボード

# ---------------------------------------------------------------

種類: サービス

APIバージョン: v1

メタデータ:

ラベル:

k8s-app: kubernetes-ダッシュボード

名前: kubernetes-dashboard-external

名前空間: kube-system

仕様:

ポート:

- ポート: 9090

ターゲットポート: 9090

ノードポート: 30090

タイプ: NodePort

セレクタ：

k8s-app: kubernetes-ダッシュボード

変更が完了したら、実行します

kubectl -n kube-system を作成します -f 。

コマンドを実行した場合の通常の出力:

サービスアカウント「kubernetes-dashboard-admin」が作成されました

clusterrolebinding.rbac.authorization.k8s.io 「kubernetes-dashboard-admin」が作成されました

シークレット「kubernetes-dashboard-certs」が作成されました

サービスアカウント「kubernetes-dashboard」が作成されました

role.rbac.authorization.k8s.io「kubernetes-dashboard-minimal」が作成されました

rolebinding.rbac.authorization.k8s.io「kubernetes-dashboard-minimal」が作成されました

デプロイメントアプリ「kubernetes-dashboard」が作成されました

サービス「kubernetes-dashboard-external」が作成されました

次に、kubernetes-dashboard Podのステータスを確認します。

kubectl ポッドを取得 --all-namespaces

名前空間名 準備完了 ステータス 再起動 年齢

kube-system kubernetes-dashboard-66885dcb6f-v6qfm 1/1 実行中 0 8分

ステータスが実行中の場合、次のコマンドを実行してポートを表示します。

kubectl --namespace=kube-system svc kubernetes-dashboard を記述します

名前: kubernetes-dashboard-external

名前空間: kube-system

ラベル: k8s-app=kubernetes-dashboard

注釈:

セレクター: k8s-app=kubernetes-dashboard

タイプ: NodePort

IP: 10.111.189.106

ポート： 9090/TCP

ターゲットポート: 9090/TCP

ノードポート: 30090/TCP このポートは外部アクセスポートです

エンドポイント: 10.244.2.4:9090

セッションアフィニティ: なし

外部トラフィックポリシー: クラスター

イベント:

注意: K8S-Dashboard インターフェースのデプロイ中に UI にログインすると、エラーが報告されます。

これは、K8S がバージョン 1.6 以降で RBAC アクセス制御ポリシーを有効にしており、kubectl または Kubernetes API を使用して構成できるためです。 RBAC を使用すると、ユーザーを直接認証して認証を管理する権限をユーザーに付与できるため、ユーザーはマスター ノードに直接アクセスする必要がなくなります。上記の展開手順に従うことでこれを回避できます。

この時点で、ARM 環境をベースとした K8S クラスターがデプロイされました。

第4節 要約

まず、ZStack のインストールと展開に関する私の経験についてお話ししたいと思います。 ZStack For ARM プラットフォームを導入してビジネス環境を構築するまでのプロセス全体は比較的スムーズです。 ZStack は製品化度が高く、インストール プロセスも非常に簡単です。基本的に、公式のデプロイメントドキュメントによれば、3 スケールのクラウド プラットフォームの構築と初期化を 1 時間以内に完了できます。

ZStack クラウド プラットフォームは独自の非同期アーキテクチャを採用しており、プラットフォームの応答性が大幅に向上し、バッチ同時操作が問題になりません。管理レベルは業務レベルから独立しており、管理ノードの予期せぬダウンタイムによって業務が中断されることはありません。プラットフォームには多数の非常に実用的な機能が組み込まれており、テストプロセス中の操作と保守のタスクが大幅に容易になります。バージョン アップグレードはシンプルで信頼性が高く、シームレスなバージョン間アップグレードが 5 分以内に完全に実現されます。実際のテストでは、アップグレード プロセスがビジネスの通常の運用にまったく影響を及ぼさないことが示されました。アップグレード後、異種クラスタ管理を実現できます。つまり、ARM サーバー上に管理ノードを構築することで、ARM クラスタ内のリソースと X86 アーキテクチャ クラスタ内のリソースを同時に管理できます。同時に、高度なSDN機能も実現できます。

ZStack クラウド ホストに基づいて K8S クラスターを構築する際、私たちのチームはソリューションを選択する際に物理マシンとクラウド ホストの間で一連の比較も行いました。比較した結果、ZStack クラウド ホストを使用して K8S クラスターを展開すると、より柔軟で制御しやすいことがわかりました。具体的には、次のような側面に反映されます。

1. ZStackクラウドホストは自然に十分に分離されている

コンテナ技術に精通している人は、複数のコンテナがホストカーネルを共有することを知っているはずです。これにより、分離の問題が発生します。技術の発展により、Linux システムの保護メカニズムを使用してセキュリティ分離を実現できるようになりましたが、あるレベルからは完全に分離されるわけではありません。クラウド ホスト方式は仮想化テクノロジの恩恵を受けており、当然のことながら非常に分離されているため、セキュリティをさらに確保できます。 ZStack は、KVM 仮想化テクノロジー アーキテクチャに基づいて独自に開発されています。

2. ZStackクラウドプラットフォームのマルチテナントのメリット

物理サーバー上で実行される多数のコンテナは、独自のリソースを管理する必要があります。いわゆるリソースの自己管理とは、各コンテナが独自のコンテナ リソースを管理することを意味します。すると、物理マシン上に何千ものコンテナがある場合に、管理範囲をどのように細分化すればよいのかという疑問が生じます。このとき、クラウド プラットフォームのマルチテナント管理が役立ちます。各テナントは対応するクラウド ホストに割り当てられ、独自のクラウド ホストとコンテナ クラスターを管理します。同時に、さまざまな担当者の権限を制御および管理することもできます。今回テストしたZStack For ARMクラウドプラットフォームでは、企業の組織構造に合わせてリソースや権限を管理でき、プロセス承認も実装できます。承認が完了すると、必要なクラウド ホストが自動的に作成されます。今後リリースされるZStack2.5.0バージョンには、リソースオーケストレーション機能も搭載される予定だそうだ。

3. ZStackクラウドプラットフォームは柔軟性が高く自動化されている

ZStack を使用すると、ビジネス ニーズに応じてクラウド ホスト リソースをカスタマイズし、リソースの無駄を削減できます。同時に、独自のビジネス状況に応じてアーキテクチャ実装モードを調整します。たとえば、コンピューティング集約型のビジネスがある場合、GPU 透過転送機能を使用して GPU をクラウド ホストに透過的に転送することで、コンピューティング タスクを迅速に完了し、面倒な設定を回避できます。

さらに、現在、さまざまなクラウド プラットフォームには、サードパーティ アプリケーションから直接呼び出すことができる対応する API インターフェイスがあり、ビジネス プレッシャーに応じてリソースを自動的にスケーリングできます。ただし、物理サーバー用の完全な API インターフェースは存在しません。基本的にはIPMIに基づいて管理されます。さらに、各メーカーの IPMI は汎用的ではないため、リソースの動的なスケーリングを実現することが困難です。 API インターフェースについて言えば、ZStack クラウド プラットフォームには完全な API インターフェースがオープンになっている機能があると理解しています。コンテナ クラスターは、ビジネス上のプレッシャーに応じて自動的にスケーリングできます。

4. 非常に優れた信頼性

なぜそう言うのでしょうか?実際、計画的および計画外のビジネスへの影響はほとんどないことは理解しにくいことではありません。物理サーバーで計画的なメンテナンスを実行すると、単一のコンテナ内で実行されている業務に必然的に影響が及びます。このとき、クラウド プラットフォームのホット マイグレーション機能を使用することで、移行プロセス中に業務が中断されないことが保証されます。計画外のダウンタイムの場合、ビジネスへの影響は基本的に毎日計算され、その損失は言葉では言い表せないほど大きくなります。クラウドプラットフォームを利用すれば、業務中断時間は数分に短縮されます。

上記では、クラウド ホストを使用して K8S クラスターを構築する利点について簡単に説明しました。もちろん、欠点もあります。私の意見では、欠点はパフォーマンスのわずかな低下に過ぎません。つまり、利点は欠点を上回ります。この問題は計画中に回避できます。たとえば、高性能なコンテナ リソースを物理ノードに集中させることで、問題を完全に解決できます。

***ZStack ARM アーキテクチャ クラウド ホストに K8S をデプロイする際に注意すべき点について、参考までに説明します。

1. デフォルトの yaml 構成ファイルに含まれるイメージ パスはすべて x86 アーキテクチャの amd64 であるため、arm64 に変更する必要があります。

2. クラスターを作成するときに、フランネル ネットワーク モードを使用する場合は、--pod-network-cidr を 10.244.0.0/16 にする必要があります。そうしないと、Pod ネットワークにアクセスできない可能性があります。

3. クラウド ホスト環境で sudo swapoff -a を実行する必要があります。そうしないと、K8S クラスターの作成時にエラーが報告されます。

以上が今回シェアさせていただいた主な内容です。誰でも注目し、コミュニケーションを取ることができます。 (qq: 410185063; メール: [email protected])。