Anthos＠Google Cloudリソース¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. Anthos¶
Anthosの仕組み¶
▼ アーキテクチャ¶
Anthosは、Anthos GKE Cluster、Anthos Service Mesh、Anthos Config Management、といったコンポーネントから構成される。
Anthos GKE Cluster¶
▼ Anthos GKE Clusterとは¶
GKE Cluster (コントロールプレーンNode、ワーカーNode、を含む) から構成される。
▼ アタッチCluster¶
AnthosのGKE Cluster部分の能力を、Kubernetesの他の実行環境 (AWS EKS、Azure AKS、RKE、K3SやK3D) のClusterに委譲する。
AnthosのKubernetesのバージョンは、各実行環境のClusterが対応するKubernetesのバージョンに依存する。
- https://cloud.google.com/anthos/clusters/docs/multi-cloud/attached/previous-generation/how-to/attach-kubernetes-clusters
- https://cloud.google.com/blog/ja/topics/anthos/getting-to-know-anthos-attached-clusters
- https://cloud.google.com/anthos/clusters/docs/attached/how-to/attach-kubernetes-clusters
- https://www.jetstack.io/blog/anthos-attached-clusters/
▼ Anthos、Kubernetesのバージョンの対応¶
Anthos Service Mesh¶
▼ Anthos Service Meshとは¶
Traffic Director、Mesh CA、Managed backends、といったコンポーネントから構成される。
▼ Traffic Director¶
サービスディスカバリーとして、istio-proxyコンテナに他の宛先の情報を提供する。
▼ Mesh CA¶
中間認証局として、相互TLS認証のためのSSL証明書をistio-proxyコンテナに提供する。
また、SSL証明書が失効すれば更新する。
Anthos Config Management¶
▼ Anthos Config Managementとは¶
一連のacm-operator (cluster-operatorなど) から構成される。
▼ acm-operatorの仕組み¶
一連のacm-operator (cluster-operatorなど) は、組み合わさって動作する。
Gitリポジトリで管理されたACMカスタムリソースのGitOpsを実装する。
注意点として、サポートしているのはACMカスタムリソースのみで、通常のKubernetesリソースをデプロイできない。
▼ cluster-operator¶
cluster-operatorは、kube-apiserverを経由して、etcdにwatchイベントを送信している。
Anthos GKE Clusterのバインディング情報がetcdに永続化されたことを検知した場合に、kube-apiserverを経由して、Anthos GKE Cluster上のkubeletにカスタムリソースの作成をコールする。
Anthos GKE Clusterが、Google Cloud以外 (オンプレミス、ベアメタル、他クラウドプロバイダー) にある場合は、cluster-operatorは、これらのAPIを経由してAnthos GKE Cluster上のkubeletをコールすることになる。
またkube-controller-managerはcluster-operatorを反復的に実行する。
これにより、Anthos GKE ClusterはCRDの宣言通りに定期的に修復される (reconciliationループ) 。
その他¶
▼ connect-gateway¶
Google Cloud上でkubectlコマンドを実行して各クラウドプロバイダー上のAnthos GKE Clusterのkube-apiserverにリクエストを送信する時に、各クラウドプロバイダーごとのAPIの違いを吸収してくれる。
▼ fleet-workload-identity¶
Google Cloud側の認証情報と、各クラウドプロバイダーのAnthos内のServiceAccountを紐付ける。
これにより、クラウドプロバイダー側でアカウントを作成する必要がない。
▼ anetd¶
cniとして、Ciliumを使用してAnthos GKE Clusterのネットワークを作成する。
02. on-オンプレミス¶
on-オンプレミスの仕組み¶
on-オンプレミスは、各Clusterを作成するワークステーション (Clusterの作成後に削除される) 、コントロールプレーンNodeの所属する管理Cluster、ワーカーNodeの所属するユーザーCluster、といったコンポーネントから構成される。
ワークステーションにて、Google CloudのAPIを経由してオンプレミス (例：VMWare) のAPIをコールし、オンプレミス環境上にAnthos GKE Clusterを作成する。
Anthos GKE ClusterのライフサイクルもGoogle Cloudから管理できる。
02-02. on-ベアメタル¶
on-ベアメタルの仕組み¶
▼ マルチClusterタイプ¶
マルチClusterタイプのon-ベアメタルは、ワークステーション (仮想サーバー) 、コントロールプレーンNodeの所属する管理Cluster、ワーカーNodeの所属するユーザーCluster、L4 (トランスポート層) のロードバランサーから構成される。
Google CloudのAPIを経由して、ベアメタルプロバイダーのAPIをコールし、ベアメタル環境上にAnthos GKE Clusterを作成する。
Anthos GKE ClusterのライフサイクルもGoogle Cloudから管理できる。
- https://itnext.io/anthos-on-bare-metal-and-akri-managing-leaf-devices-on-edge-kubernetes-clusters-from-cloud-222ff17dd7b8
- https://medium.com/google-cloud-jp/%E7%B0%A1%E5%8D%98%E6%A7%8B%E7%AF%89-nuc-%E3%81%A7%E3%81%8A%E3%81%86%E3%81%A1-anthos-%E3%82%92%E5%8B%95%E3%81%8B%E3%81%97%E3%81%A6%E3%81%BF%E3%82%88%E3%81%86-682e95112116
▼ スタンドアローンClusterタイプ (ハイブリッドタイプ)¶
スタンドアローンClusterタイプ (ハイブリッドタイプ) のon-ベアメタルは、ワークステーション (仮想サーバー) 、コントロールプレーンNodeとワーカーNodeの両方が所属するベアメタルCluster、といったコンポーネントから構成される。
ワークステーションにて、Google CloudのAPIを経由してベアメタルプロバイダーのAPIをコールし、ベアメタル環境上にAnthos GKE Clusterを作成する。
Anthos GKE ClusterのライフサイクルもGoogle Cloudから管理できる。
- https://itnext.io/anthos-on-bare-metal-and-akri-managing-leaf-devices-on-edge-kubernetes-clusters-from-cloud-222ff17dd7b8
- https://medium.com/google-cloud-jp/%E7%B0%A1%E5%8D%98%E6%A7%8B%E7%AF%89-nuc-%E3%81%A7%E3%81%8A%E3%81%86%E3%81%A1-anthos-%E3%82%92%E5%8B%95%E3%81%8B%E3%81%97%E3%81%A6%E3%81%BF%E3%82%88%E3%81%86-682e95112116
ワークステーション¶
▼ ワークステーションとは¶
Anthos Clusterの作成時やアップグレード時に、bmctlコマンドはワークステーション (仮想サーバー) を構築し、ワークステーション上でKindを起動する。
ベアメタルであるため、自前で仮想サーバー (例：VMware) を作成する必要がある。
Kindはコンテナを構築し、そのコンテナ内でブートストラップClusterを作成できるか否かを検証することにより、Anthos Clusterの事前検証する。
Kindがコンテナを構築するために、Anthos Clusterの構築前に、dockerプロセスを起動しておく必要がある。
$ systemctl start docker
▼ ブートストラップCluster¶
Kindがコンテナ内で作成する仮想Anthos Clusterのこと。
VClusterを使用して、仮想Anthos Clusterを作成している。
~/baremetal/bmctl-workspace/foo-anthos-cluster/.kindkubeconfigファイルを指定することにより、ブートストラップClusterのkube-apiserverにリクエストを送信できる。
$ kubectl get pod \
-n foo-namespace \
--kubeconfig ~/baremetal/bmctl-workspace/.kindkubeconfig
02-03. on-Google Cloud¶
on-Google Cloudの仕組み¶
Google Cloud環境上にAnthos GKE Clusterを作成する。
02-04. on-クラウドプロバイダー¶
on-クラウドプロバイダーの仕組み¶
Google CloudのAPIを経由して、他のクラウドプロバイダー (例：AWS、Azure) のAPIをコールし、クラウドプロバイダー上にAnthos GKE Clusterを作成する。
ただし他のクラウドプロバイダーでは、専用Kubernetes実行環境 (例：AWS EKS、Google Cloud GKE、Azure AKSなど) を使用すれば良いため、Google Cloud環境、オンプレミス環境、ベアメタル環境、でAnthosを使用することが多い。
03. bmctlコマンド¶
check preflight¶
▼ check preflightとは¶
bmctl upgradeコマンドの実行時に実施されるプリフライトチェックのみを実施する。
$ ~/baremetal/bmctl check preflight -c foo-anthos-cluster -n foo-namespace
update¶
▼ updateとは¶
CRDの設定値を変更し、kube-apiserverに送信する。
$ ~/baremetal/bmctl update cluster -c foo-anthos-cluster -n foo-namespace
upgrade¶
▼ upgradeとは¶
AnthosのKubernetesのバージョンをプリフライトチェックで検証し、成功すればアップグレードする。
$ ~/baremetal/bmctl upgrade cluster -c foo-anthos-cluster -n foo-namespace
▼ --reuse-bootstrap-cluster¶
既存のブートストラップClusterを再利用することにより、プリフライトチェックの一部をスキップし、成功すればアップグレードする。
$ ~/baremetal/bmctl upgrade cluster -c foo-anthos-cluster -n foo-namespace --reuse-bootstrap-cluster