vCSA6.7U3 + vSAN環境での"Cloud Native Storage"項目について 【2 -導入 ；vSphere環境への連結編】
Announcement：本記事は複数に分けている記事の2番目となります。
一番目の記事をご確認されたい方は以下リンクへアクセスいただければ幸いです。
vCSA6.7U3 + vSAN環境での"Cloud Native Storage"項目について 【1 - 事前準備；Kubernetes Cluster構築編】
https://pocmemo.hatenablog.com/entry/2020/01/13/161344
Kubernetes ClusterをvSphere環境へ接続するまで
導入環境：
初回の記事でも記載しましたので簡単に再掲として記載しておきます。
なお、特にKubernetesはライフサイクルが非常に速いので、
記事掲載日時と各種バージョンリリース等にご注意いただければ幸いです。
・Nested vCSA 6.7 Update3
・ Nested vSAN 6.7 Update3(今回はAll FlashですがHybridでもOKです)
・Ubuntu 18.04 - LTS *3台
・kubernetes v1.14.2-00
※ 記事掲載時点での最新は1.17.0
・CNI：flannel
・公式Docs：https://docs.vmware.com/jp/VMware-vSphere/6.7/vsphere-673-cloud-native-storage.pdf
前回の記事により、以下のようにKubernetes Clusterを構築した段階まで
ご紹介させていただきました。
今回は以下状態からの続きとなります。
本記事ではKubernetesとvSphereが連携可能になるまでを確認していきます。
次回記事で実際の挙動等について追いかけたいと思います。
前回完了時点：Kubernetes Clusterを構築完了した時点から再開します。
Cloud Controller Managerの導入
そもそもCloud Controller Managerとはどのようなものでしょうか。
Kubernetesはその設計・目的上様々なクラウド環境へ接続する事を半ば前提として
設計・改良が進められています。
しかしご存知のように今や"クラウド"と言ってもサービスを展開している企業は
非常に多数存在しており、それぞれ違うソースコードであるのに対して
Kubernetesが各接続先クラウドのコードを認識できなくてはなりません。
プロビジョニングされる接続先環境を、k8sが認識する為に必要なマネージャが
この"Cloud Controller Manager"となります。
以下Kubernetes公式Docsから引っ張ってきたアーキテクチャです。
今回はクラウドではなくオンプレミスのvSphere環境が接続先となりますが、
接続先の認証を正しく出来るようにするためこのマネージャが使用されます。
とりあえずは"Kubernetes ClusterがvSphere環境を認識するために必要なもの"
と把握いただいて問題ありません。
実際の導入手順について
※ 本記事で実行する内容は特段の記載がない場合すべてMaster Node上での作業です。
実際の導入手順ですが、まずはconfigmapを事前作成し、環境のvsphere情報を
Kubernetes Cluster側で正しく把握できるようにしておきます。
・公式Docsの以下記述について確認いたします。
a configmap cloud-config vsphere.conf ファイルを定義します。
上記項目にて、公式Docsには以下のように記述されております。
基本的に以下に沿う形式で記載すれば問題ないです。
[Global]
insecure-flag = "true"
[VirtualCenter "vCenter Server IP address"]
user = "user"
password = "password"
port = "443"
datacenters = "datacenter"
[Network]
public-network = "VM Network"
上記について、例えば私の環境だと以下記述で実施しました。
[Network]については今回テスト環境で特段指定の必要が無かったため
割愛しております。
vCenterを複数参加させたい場合、下記のようにエントリを増やせばOKです。
[Global]
xxxx
[VirtualCenter "x.x.x.x"]
xxxx
[VirtualCenter "y.y.y.y"]
xxxx
テスト環境でない方は、"Secretを使用したい"というニーズが出てくるかと思います。
その場合は以下のように記述する事でSecretを使用可能です。
vsphere.confに対し、以下のように記述
[Global]
port = "443"
insecure-flag = "true"
[VirtualCenter "10.10.38.150"]
secret-name = "vsphere-config-secret"
secret-namespace = "kube-system"
別途以下のように記述されたyamlファイルを作成し、--from-fileで指定して
kind: Secretのデプロイを実行する
apiVersion: v1
kind: Secret
metadata:
name: vsphere-config-secret
namespace: kube-system
stringData:
10.10.38.150.username: "administrator@vsphere.local"
10.10.38.150.password: "VMware1!"
その後実際にvsphere.confからcomfigmapを作成します。
・kubectl create cm cloud-config --from-file=<path>/vsphere.conf -n kube-system
作成確認のコマンドは以下となります。
・kubectl get cm cloud-config -n kube-system
Configmap作成後、実際に導入を実行していきます。
公式DocsにはTaintを確認する項目もございますが、こちらについても
念のため必ず実行をしておきましょう。
・kubectl describe nodes | egrep "Taints:|Name:"
余談ですがTaintとは各Nodeに対して設定するもので、これが設定されていると
Taint設定値の合わないPodの配置を拒否する動作が走ります。
WorkerNode上に予期せぬPodの配置を避ける為に設定される場合がほとんどです。
Master Nodeに対してデフォルトでシステム系以外のPodが配置されないのも
このTaintを利用しているためです。
上から一行ずつ実行をしていきます。
・kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-roles.yaml
kind: ClusterRoleが設定されます。
・kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-role-bindings.yaml
kind: RoleBindingが設定されます。
・kubectl apply -f https://github.com/kubernetes/cloud-provider-vsphere/raw/master/manifests/controller-manager/vsphere-cloud-controller-manager-ds.yaml
kind: ServiceAccount,DaemonSet,Service が設定されます。
実行後、各Nodeに対してProviderIDが発行されているか確認してみてください。
このProviderIDが正しく発行されていない場合は以下を改めて確認してみてください。
1. 作成したvsphere.confは正しい値を入れられているか
2. 各種実行して作成されたリソースは正しく設定・構築されているか
3. kubectl describeで作成された各項目を確認し、Event項目でErrorを出力しているか
CSI Driverの導入
事前準備の最終段階がこの"CSI Driver"の導入となります。
CSIについてもこのタイミングで確認したいと思います。
CSI(Container Storage Interface)はKubernetesとvSphere環境間で
ストレージのプロビジョニングに関するやり取りを司るコンポーネントです。
この場合、Kubernetesが"ストレージの要求をする側"、
vSphere環境が"Kubernetes Clusterからの要求に応える側"として疎通を実施します。
この機能により、必要に応じてvSphere環境に存在するストレージ容量を切り出して
Kubernetesに払い出す事が可能となります。
以下の画像はvmware社で公開された画像の一部となります。
Kubernetes Clusterに"CSI"と記載されているコンポーネントが今回導入するDriverで、
このCSIが"CNS Control Plane"と疎通を図る様子が記載されています。
この"CNS Control Plane"とは"vCenter"を指してます。
vCSA 6.7 Update3を導入した際デフォルトでクラウドネイティブストレージの項目が
存在している事からもわかるように
CNS Control PlaneはデフォルトでvCenterに組み込まれているため、
このCNS Control Planeの導入作業は必要ありません。
実際に実行する手順については公式Docsにも記載があるように、
ほとんどがCloud Controller Managerの導入時に行った手順と類似しています。
csi-vsphere.conf
[Global]
cluster-id = "cluster-id"
[VirtualCenter "vCenter Server IP address"]
insecure-flag = "true"
user = "user"
password = "password"
port = "443"
datacenters = "datacenter"
先ほど作成した時とほとんど同じ内容ですね。
※ cluster-id = "cluster-id" 当該行についてですが、
どこかでUUIDなどをチェックする必要はありません。
管理しやすい文言を好みで付与するだけでOKです。
私はCluster名が"test-vSAN"だったので、同じでいいか...とそのまま付けました。
複数のKubernetes Cluster環境下ではそれぞれ違うIDを設定しておくのが無難です。
以下コマンドを入力し、作成を実行します。
・kubectl create secret generic vsphere-config-secret --from-file=csi-vsphere.conf --namespace=kube-system
その後、公式Docs記載の”2 vSphere CSI ドライバに必要なすべてのコンポーネントを展開します。” へ移ります。
実際にこの作業によりRepositoryからPullされてくるイメージ一覧は以下となります。
image: quay.io/k8scsi/csi-attacher:v1.1.1
image: vmware/vsphere-block-csi-driver:v1.0.0
image: quay.io/k8scsi/livenessprobe:v1.1.0
image: vmware/volume-metadata-syncer:v1.0.0
image: quay.io/k8scsi/csi-provisioner:v1.2.1
image: quay.io/k8scsi/csi-node-driver-registrar:v1.1.0
なおこの辺から teeコマンドで記述していくには少し長くなってきてますので
管理端末でコピー&ペーストしてmasterへscpで送ったりするのがいいかなと。
私のようにただテストするだけであればubuntuにdesktopを追加し、
Docsから直接viエディタでペーストしてしまうのも早いです。
・kubectl create -f csi-driver-deploy.yaml
導入後の状況は以下となります。
導入コンポーネントの動作確認
さて、Kubernetes側の設定はこれですべて完了しましたが、
この設定が完了した瞬間にGUIに何か通知が到着するわけではありません。
実際にVolumeの作成が正しく出来るかどうかの確認が必要となります。
残るは"KubernetesからのVolume要求に、vSphere側が応えられるか否か"
確認したいと思います。
なお実際に払い出しが実行されるまでの内容は以下となります。
1. 事前にvSANの仮想マシンストレージポリシーを作成する
2. StorageClassを設定し、Dynamic Volume Provisioningの実行準備をする
3. Volumeの要請に応じてvSphere環境側がVolumeを準備する
※ 今回のテストではStatefulset作成と同時にVolumeの払い出しが行われます。
4. 手順1番で作成したポリシーに則ってVolumeの作成がされる
vSANのポリシー作成についてはご存知の手順でOKです。
今回は"k8s-policy" として作成しており、内容はvSAN default policyと同一としてます。
また、Kubernetesを導入したUbuntu OSに割り当てられているポリシーとは
別のポリシーを割り当てても問題ありません。
実際にStorageClassを作成する際、Policy名を指定する必要があります。
このPolicy名は先ほどvSphere Client画面で作成したpolicy名と
同一にする必要があります。
Storage Class作成後、以下のようなテスト用statefulset・PVCを作成してます。
なお余談ですが私は手順の一番最初で、仮想マシンに対してdisk.EnableUUIDを
設定しないまま進めてしまい、PodがPendingのままSTOPしてしまいました。
対処：Worker Nodeを kubectl drain コマンドで安全に停止し、
停止した状態でVM上にパラメータを追加。
Worker起動後にkubectl uncordonでClusterに再参加させました。
なおその際の画像をたまたま収めてありました。
statefulsetはREADY：0/3だったんですが一つ目のVolumeは作成完了してましたね。
状況としては以下のような状態だったのだろうと推察しております。
"1個目Volumeを作成(その時点でVolumeはvSphereへ反映)するも
その後1個目のStatefulsetが当該Volumeをマウント出来ず再試行を繰り返す"
参考：一つだけVolumeができている(正しいのは3つ作成されている状態)
実際にKubernetesから払い出し要請を受けた瞬間、vSphere Client側で
以下のような履歴が残ります。
vSphere Client GUIで"コンテナボリュームの接続"と表示がされるのは
感慨深いというか何というか、新たな時代を感じる事が出来ていいものですね。
実際のVolume認識状況はどうか確認すると、k8s上 / vSphere上双方で
問題なくVolumeの表記が確認されました。
以下より、vsanDatastoreで正常にVolumeが作成されている事も確認ができました。
ProviderIDが正常に取れている事は先程確認しておりましたが、
Volumeの作成やvSphere Clientへの認識が問題ない事から、
CSIについてもひとまず導入については成功していると見てよさそうです。
今回はvSphere Clientへ各種設定・Driver設定が完了したところまで確認致しました。
Kubernetes環境とvSphere環境への更なる連携はまた次回。
vCSA6.7U3 + vSAN環境での"Cloud Native Storage"項目について 【1 - 事前準備；Kubernetes Cluster構築編】
vCSA 6.7 Update 3を導入されている環境をお持ちの方について、
"監視"項目で"クラウドネイティブストレージ"についてお気づきになられた方は
いらっしゃいますでしょうか。
CSA6.7 Update3がリリースされてから日数も経過していて、やや今更感もありますが
とりあえず内容について確認してみました。
Cloud Native Storageの監視項目について
そもそもこの項目はどのように表示されるのでしょうか。
既に構築を実施してしまいましたが、監視可能な状態にした時の表示は
以下のようなイメージです。
※ 私の検証環境で警告が出現しておりますが、Kuberentesを構築したものとは
無関係の容量関連エラーが出ているだけですのでお気になさらず。
Kubernetesを触ったことのある人であればなんとなくイメージが湧くかと思います。
この項目ですが、GuestOS(Kubernetes Cluster)上に存在しているVolumeを
vSphereから監視している状況を示しております。
ある種当然ですが、Kubernetes環境を構築していない人にとっては無縁の項目で
特段気にする必要も無い項目になります。
しかし、実際にKubernetes環境の構築を検討されている方や
vSANの環境はあるからとりあえずテストしてみたい！という方など
様々いらっしゃるかとおもいますので備忘録を兼ねて投稿したいと思います。
なお非常に長くなってしまいましたので、
今回は一旦このテスト環境を構築するまでの事前準備編として記載したいと思います。
実際のDriver導入やVolume Claimの様子は別途記載の予定です。
今回はKubernetes Cluster構築にあたるかなり基礎的な内容がほとんどとなりますので
事前にご了承いただければ幸いです。
Cloud Native Storage構築テスト環境
今回テストするにあたり私が準備した環境は以下です。
・Nested vCSA 6.7 Update3
・ Nested vSAN 6.7 Update3(今回はAll FlashですがHybridでもOKです)
※ Cache Tier：20.00GB / Capacity Tier：25.00GB
1+1=2 DisksでのDisk Groupが各ホストに1つずつのシンプルな構成
・Ubuntu 18.04 - LTS *3台
各GuestOSは vCPU：2 / 4GB Memory の構成です。
当初3台ともserver版で導入しておりましたが、途中でちょっとした事情により
Master NodeだけDocker CEのインストール前に
apt install ubuntu-desktopを実行しております。
・kubernetes v1.14.2-00
※ 記事掲載時点での最新は1.17.0
このKubernetes versionについて余談ですが、
こちらはCompatibilityが定められておりますのでお気を付けください。
基準：kube api-server となり、このversionを"X" とした場合
・controller-manager：X or X-1
・kube-scheduler：X or X-1
・kubelet：X or X-1 or X-2
・kube-proxy：X or X-1 or X-2
・kubelet：X+1 or X or X-1
例えばkube api-serverが1.10.の場合
X or X-1とは1.10.もくは1.09を指しております。
・CNI：flannelを使用しております(どうせならNSX-Tにすればよかった...)。
構築に関する参考は以下のDocsとなります。
記事内で以下公式ドキュメントを見ていただくような記載をしておりますが
これは無駄な記事の長文化を避けるためのものとなりますのでご了承ください。
https://docs.vmware.com/jp/VMware-vSphere/6.7/vsphere-673-cloud-native-storage.pdf
事前準備
vSAN Cluster上にUbuntu 18.04を3台準備しておきます。
その際、"disk.EnableUUID"を"True"に設定しておくことを忘れないようにしましょう。
※ 私はすっかり失念しており、構築の最終段階で無駄な時間を取られました。
ここについては別途テスト時の記事で記載したいと思います。
そのほかについては、通常のVM作成と同じ手順で問題ありません。
またご存知の方もいるかと思いますが、実はUbuntu OSはインストール時に合わせて
関連サービスを導入する事が可能です。
Ubuntu OSを導入時、以下画面でいくつかKubernetes関連サービスが表示されます。
今回は手動で必要サービスを全てインストールしていくので、
特段何も選択せずに進んで問題ありません。
aws-cliやgoogleのSDK等は必要に応じて...ですが今回の私の環境はオンプレミスのため
この辺も何も触れず進んでいきました。
Ubuntu導入後からKubernetes導入まで
以下に記載するコマンドは、Master / Workerどちらでも共通で実行するコマンドです。
そのため作業量はKubernetes Cluster参加予定台数分実行する必要があります。
今回私は使用しませんでしたが、億劫な方はtmuxで実行したほうが時短かなと。
Kubernetesの構築経験のある方にとってはある種"お馴染みの"コマンドばかりですが
念のため記載いたします。
とりあえず初めてKubernetesを構築する！という方や
Linux操作にあまり自身の無い方は、上から順に入力いただければ問題ありません。
一台ずつ最初から最後まで実行するか、一行ずつ全台で並行して作業するか
こちらについてはどちらでも問題ないのでお好みで。
・sudo su -
・passwd
ご存知 Ubuntu OSにroot passwordを設定するコマンドです。
今回テストで実行しているだけなのですべてroot権限で実行してます。
今後出てくるコマンドについて、root権限で操作されない方は必要に応じて
先頭にsudoを付与して実行が必要になりますのでご注意ください。
・swapoff -a
このコマンドは忘れがちですが重要です。
必要に応じて/etc/fstabの設定をして、swapoffを確実にかけておく必要があります。
なお忘れていた場合もKubernetes ClusterのInit段階で警告が出現し失敗するので
気づけるタイミングはあります。
・apt-update
・apt-get install -y vim openssh-server
vimについては言わずもがなですが、後々Master Nodeから各Worker Nodeに対して
ファイルを送りたいタイミングが出てきます。
手順は何でも問題ないですがSSHを有効化しておくのがお勧めです。
【Docker CEの事前インストール】
今回は新規でKuberentes Clusterを構成しているため、Docker CEも導入します。
あまりに古くなければversionは不問ですが、今回は公式Docsにも記載されている
"version：18.06.0~ce~3-0~ubuntu" を指定してます。
・apt install apt-transport-https ca-certificates curl software-properties-common
・curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
・add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable"
・ apt-get update
・apt-get install docker-ce=18.06.0~ce~3-0~ubuntu
・ vi /etc/docker/daemon.json
Docsにはcat + EOFで書き込む方式で記述されていましたが
私はvimで直接ファイルに書き込んで実行しております。
以降の入力コマンドについても、大体vimで書いて対応しました。
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}
・mkdir -p /etc/systemd/system/docker.service.d
・systemctl daemon-reload
・systemctl restart docker
作成したファイルを読み込ませるために上記3行を別途入力します。
Dockerのリスタートも忘れないようにしましょう。
今回は念のためdocker run hello-world コマンドでDockerが正常動作しているか否か
確認致しました。入力してはいけないわけではないので参考までに。
Docker CEの導入が完了したら次にKubernetes関連サービスの導入です。
下記について、順序を守り導入をしていきましょう。
・curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
・vi /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
・apt-get update
・apt-get install -qy kubeadm=1.14.2-00 kubelet=1.14.2-00 kubectl=1.14.2-00
※ 記事掲載時点で、このバージョンを指定しない場合は1.17.0が導入されるはずです。
curlコマンドを実行する前にapt.kubernetes.ioを追加して、なおかつ
apt-get updateしてしまった場合、apt-get updateが失敗します。
おそらくこの時点で気づけるのですが、その場合は一度kubernetes.listを削除し
改めてapt-get updateを実行しましょう。
状態がもとに戻りますので、改めて上記コマンドの一行目から同じ作業を実行します。
Kubernetes Clusterの構築
ここまでが事前準備で、やっとKubernetes関連サービスの導入に進んでいきます。
公式Docsにおける"マスターノードの初期化"へ進んでいきます。
なおKubernetesの導入ですが、ざっくり言うとこんな感じです。
1. Master NodeでKubernetesを動作させるためのInitializationをかける
2. 各Worker Nodeを、Masterへ参加させていく
そのためWorker Nodeの準備前に、MasterのInitをかける必要があります。
なお今までやってきた事前準備については各ノード共通で実行をしておりますので
Masterをどれにするかは考慮の必要がありませんでしたが
ここから先の作業は "どれをMaster Nodeとして動かすか" について考慮したうえで、
自分で決定されたMaster Node上での作業となります。
公式Docsに記載されているkubeadm init構成ファイルについて
早速公式Docsに記載されている以下手順に沿って作業を進めていきます。
1 マスター ノードの kubeadm init 構成ファイルを作成します。
この構成ファイルについて注釈程度に記載しておきます。
まず、この公式Docsではここから先、ファイルがすべて/etc/kubernetes 配下に
保管される記述となります。
別のDirectoryを指定したい方は適宜変更しても動作は問題ありません。
また、ここから先は一部Docsにはパス省略で記載されているため、
構築に不安のある方は
cd /etc/kubernetes/ コマンドをこのタイミングで入力しておくと安心かと思います。
ここまで上記紹介してきたコマンドをそのまま入力されている場合、
基本的にここのファイルも丸写しで問題ありません。
しかし Kubernetes Versionが1.14.2-00でない方は
kubernetesVersion: v1.14.2 行を適宜変更する必要があります。
またflannelを使用しない場合、podSubnet: "10.244.0.0/16" 行も適宜変更が必要です。
・kubeadm init --config /etc/kubernetes/kubeadminitmaster.yaml
上記コマンドを入力すると、手順１番で作成したyamlファイルに沿って
Kubernetesの初期構築がスタートします。
Initが正常に終了すると、出力内容の末尾付近に以下記述があります。
気づきにくいですが注意して確認しておきましょう。
To start using your cluster, you need to run the following as a regular user:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
公式Docs手順3番には上記のうち2行しか記載されておりませんが、私は毎回念のため
Kubernetesから指定されている上記3行すべて入力して構築してます。
この手順が終了すると、Master Nodeでkubectlコマンドなどが通るようになります。
一応以下コマンドで確認してみましょう。
・kubectl get pod -n kube-system
いくつかのPODがMaster上で配置され、動作している事が確認できます。
なお公式Docsにも記載されているように、私の環境でもcorednsのpodのみ
"Pending"のステータスとなりましたが、これは現時点では問題ありません。
後々ちゃんとRunning statusになります。
次の手順4番でflannelを導入してきます。
公式Docsでは以下が指定されておりますが、私は以下2つ目のURLからFlannelを導入しました。
上記URLを試した訳ではないのですが、以下のURLについては私の以前の作業で
導入実績があったため使用しただけです。
心配な方は下記URLを指定してkubectlコマンドを入力するといいかなと思います。
導入後以下コマンドをもう一度入力すると、Flannel関連のPodが視認できます。
・kubectl get pod -n kube-system
この時点でcoreDNS以外のPodがRunningでない方は、一度5分待ってみましょう。
5分待っても変わらない方は kubectl describe pod <pod name> を入力し
最下部にあるEvent項目を確認してみましょう。
Podに関するErrorログが出力されております。
この後いよいよWorkerを追加していくのですが、
Workerに対してMasterを認識させるため、あるファイルを使用します。
そのファイルを作成するためのコマンドは以下です。
・kubectl -n kube-public get configmap cluster-info -o jsonpath='{.data.kubeconfig}' >
discovery.yaml
このコマンドを入力後、各Workerに対してこの"discovery.yaml"を送付する必要があります。
Workerに対して何らかの方法で共有すれば問題ありませんが、
私はSCPを使用しました(そのため事前にSSHを有効化しておりました)。
・scp /etc/kubernetes/discovery.yaml <user>@<IP address>:~/
上記コマンドでは送付先が/home配下となりますので
必要に応じてWorker Node上でファイルを移動させておきましょう。
以降の作業を踏まえると、確実なのはworker node上の/etc/kubernetes/配下がいいかなと思います。
・mv /home/<user>/discovery.yaml /etc/kubernetes/
Worker Nodeの初期化
先ほどのファイルを各Worker Noeへ送付したら、
公式Docs内 "ワーカーノードを初期化する” へ移ります。
kubeadm join構成ファイルの作成時、考慮する点の注釈ですが、
discovery:
file:
kubeConfigPath: /etc/kubernetes/discovery.yaml
上記記載にあるように、先ほどMasterからWorkerへ送付したyamlファイルについて
どこに保存されているか事前の指定が必要です。
ファイル名やディレクトリパスを変更されている方は、ここの記述に注意しましょう。
ファイルを作成したら、作成ファイルを使用してClusterに追加すれば
事前構築作業は完了となります。
・kubeadm join --config /etc/kubernetes/kubeadminitworker.yaml
少々待機した後、Master Node上で以下コマンドを入力し確認してみましょう。
・kubectl get nodes -o wide
私の環境だと公式Docsとは違い、Workerを2台としておりますので
上記のようにMasterとWorker *2で合計3台表示されております。
このコマンドから以下のことがわかります。
・Clusterは3台存在している (エントリーが3行のため)
・"k8s-master" がMasterとして動作している。また、Master 1台構成である
(ROLES より1台だけ"master"で、ほかの2台が"<none>" のため。
ここは<node>表記で問題ないです。)
・Kubernetes version：1.14.2 を使用している
・docker-CE：version：18.6.0を使用している
上記のようにKubernetes Clusterを構築出来たら、ようやくスタートラインです。
次回以降、Cloud Native Storageの設定を進めていきます。
VMware OS Optimization Tool (OSOT)の操作について
今回はVMware社が無償公開しているツールのご紹介です。
HorizonのMaster Imageを作成する際、例えばデフラグやUpdate自動化の無効化など
チューニングの考慮点が多いのは導入障壁の一つとなります。
この導入障壁ハードルを下げるという目的に一役買ってくれるツールとなります。
VMware Flingsから公開されている"OS Optimization Tools" と命名されています。
このOS Optimization Tool (OSOT)は下記からダウンロードが可能です。
https://flings.vmware.com/vmware-os-optimization-tool
余談ですがこのFlingsはこのOSOT以外にも有用なツールを揃えており、
時間があるときに他のツールについてもご紹介できたらいいなという所存です。
OS Optimization Toolの紹介
このOS Optimization Toolですが、VDI・RDSHどちらのMaster Imageであっても
共通で使用することが可能です。
使用する要件としては以下2点となります。
- PC用OSであればWindows 7 / 8 / 8.1 / 10
Server用OSであればWindows Server 2008 / 2012 / 2016,2019
上記のいずれかのOSであること (2008, 2012はR2を含みます。) - .NET Framework 3.5 SP1以上が導入されている事
https://www.microsoft.com/ja-jp/download/details.aspx?id=22
※.NET Framework 3.5以上が導入されている環境の場合、
上記要件より古いOSでも動作する可能性はありますが
後述するテンプレートが存在しないため実質使用できません。
導入手順について
※ 当該記事はversion：b1130を使用しております。
導入環境：
Oracle Virtual Box (もはやESXi上ですらない...)
GuestOS：Windows Server 2012 R2 standard edition
User：Local Administrator権限でログイン
.NET Framework： v3.5 導入
導入手順は非常にシンプルです。
ざっくり言うと以下3工程です。
1. 上記のURLからZIPファイルをダウンロードする
2. ダウンロードしたZIPファイルを解凍する
解凍すると、以下ファイルが出現します。
3. アプリケーションを起動する
※ なおこのアプリケーションはインストール作業は必要ありません。
ワンタイムで実行されるアプリケーションのため再起動も要求されません。
念のため起動後のアプリケーション一覧を確認しておりますが、
インストールされた履歴もありません。
環境によっては.NET Framework導入が障壁になる可能性もありますが、
そうでない場合、不必要なアプリケーションの導入が必要ないのは有難いですね。
実際に起動した際の画面はこちら
Publisher: VMware, Inc.と表記されてますね。
RUNを選択し、少々待機(私の環境では数秒程度)すると以下画面が表示されます。
この画面がOSOTのダッシュボード的なメインの画面となります。
デフォルトでは上部タブの"Analyze"が開かれた状態で表示されます。
少し触れるとなんとなく画面の意味もわかってきますが、こんな感じです。
左上窓：OSのシステム情報画面
右上窓：Optimization未実施項目 / Optimization済項目
左下窓：Optimization項目をインベントリするテンプレートと各項目一覧
右下窓：左下窓で表示されている各項目の詳細
なおシステム情報を読み取り、
自動でWIndows Server 2012用のテンプレートを当ててくれていますが
左下窓を操作し、手動でテンプレートを変更することも可能です。
このテンプレートはデフォルトで導入されておりますが、
上部タブの"Public Templates"を使用することでデフォルトでないテンプレートも
同様に使用する事が可能です。
この辺は有志作成のFlingsらしく、ソーシャル評価機能(thumbs-up)がついていますね。
"Verified" 項目もありますので、使用基準の一つとしてもいいかと思います。
Optimize実行について
実際に最適化する手順も非常にシンプルです。
1. 適宜最適化する項目を選択する。
※ 実施をしない項目は右下窓でチェックを外すだけでOKです。
2. 画面最下部右側の"Optimize"を押下する
※ "本当に実施しますか?" といった確認も無く実行されますので要注意です。
間違えて実施してしまった場合はロールバックが可能です(後述)。
項目が多く全て掲載することが出来ず申し訳ないですが
Optimize実行前と実行後の画面で雰囲気だけでも伝われば幸いです。
Optimize実行前画面：
画面最下部左側 "Optimize"を押下すると、少々待機した後に"Optimize"というタブが増えて
自動で以下画面へ遷移します。
その後"Analyze"画面へ戻ります。
なおAnalyze画面へ戻っても表記が変わっているように見えませんが、ここは改めて
画面最下部左側の"Analyze"ボタンを押下してください。
すると以下のようにほぼすべての項目に緑チェックが付いている事がわかります。
右上窓も青色の項目が圧倒的に多くなってます。
Optimize実行後：
RollBackについて
RollbackもOptimize実行同様にシンプルです。
上部タブの"History"から実施します。
このタブを選択すると以下のような画面が出現します。
今回検証にあたり事前に一度Rollbackをしてしまっているため履歴が残ってしまっておりますが
手順としてはOptimize実行時、自動で作成される復元ポイントにチェックを入れて
最下部右側の"RollBack"を押下するだけです。
なお念のため一度この画面を終了し、改めて開きなおしてみましたが
問題なく履歴が残っておりますので、Optimize実行後、画面を閉じてしまった後でも
RollBackが可能です。
使用時の注意点
実際に使用する時の注意点ですが、このアプリケーションが
無償公開されており、使用にあたりVMwareライセンスが必要とされない事から
各サポート窓口で当該アプリケーションのサポートを承っているか否かについては
必ず事前にご確認されたほうがいいかと思います。
以上、簡単ではございましたがOSOTのご紹介でした。
Nutanix環境におけるESXi整合性の確認について
Nutanix環境 + ESXi 使用時の整合性について
ちょくちょく質問を受ける、"Nutanix環境でのESXiの整合性について"
紐解いて確認していきたいと思います。
※ 事前のお断りで恐れ入りますが、各種筐体のベンダーにより個別で保持している特殊な要件が無いか否かは別途ご確認をお願い致します。
NutanixとFirmwareに対して直接のCompatibilityは (ほとんどの場合)存在しない
"Nutanix環境をUpdateしようとしているがFirmwareの整合性はどのように確認したらいいか"
という質問を社内外問わずいただくことがあります。
こちらについては多くの場合、"ハイパーバイザの構成状況次第" が回答となります。
そもそもNutanixのCompatibilityを確認すると、ハイパーバイザのバージョンくらいしか確認項目がありません。
https://portal.nutanix.com/#/page/compatibilitymatrix
Nutanixから見たときに重要となるのはFirmwareというよりもESXiとなります。
他方ESXiから確認した時に重要となるのはVIBとFirmwareの整合性です。
Firmwareから見たときにNutanix機能で重要になる場面は稀で、多くの場合ESXiとの整合性がとれていれば問題ありません。
まとめると相関はこのような関係です。
Nutanix ←→ ESXi ←→ Hardware
結果実施する手順に相違はありませんが、"どのコンポーネントのUpdateが必要であるか"に即したときに
個人的に確認がしやすいと感じるアプローチについて記載いたします。
1. NutanixのAOSをUpdateを実行する事が目的である場合
この場合、まずはそのバージョンへのアップデートを予定しているAOSバージョンに対応しているハイパーバイザバージョンを確認しましょう。 ( Nutanix ←→ ESXi )
現行のESXiが上記で記載したCompatibility Matrixに含まれている場合、必ずしもESXiのアップデートは必要ないと判断されるため
Nutanix関連コンポーネントだけアップデートすれば問題ありません。
ESXiについてもついでにアップデートしたい場合は下記2番をご参考にESXiについて確認が必要となります。
2. ESXi Updateが必要となり、それに伴いAOSをupdateする場合
ESXiのupdateを実施する場合、Nutanix環境では、各種要件を満たす場合Prism GUIからのアップデートが可能です。
要件としてvSphere DRS機能が有効化されている(= vSphere Enterprise ライセンスで運用している) 必要がありますのでこちらは事前に確認しておきましょう。
https://kb.vmware.com/s/article/2109507?lang=ja
Prismを使用しない通常のUpdateも勿論問題ありませんので、ケースバイケースで選択できるようにしておくことが大切です。
Prism上からUpdateを検討している場合、Nutanixのサポートポータルからダウンロードできるjsonファイルで確認が可能です。
https://portal.nutanix.com/#/page/static/hypervisorDetails
試しに "6.5.0-u3-13932383-Dell-A00.json"ファイルを使用し確認してみます。
実行可能な条件は以下2点です。
・現行ESXi versionが "upgrade_from": [ 内に含まれているESXiのversionであること
・ 現行AOS versionが "nos_version": [ 内に含まれているAOS versionであること
※ Nutanix AOSは以前NOSと呼称されており、その名残で"nos_version"と表記されております。
3. Hardware Firmwareのアップデートが必要で、それに伴いESXiやNutanixのUpdateが必要か否か確認したい場合
上記の場合はまず ESXi ←→ Hardware の観点から確認が必要です。
特定のFirmwareをupdateする場合、多くの場合はVIBのアップデートが必要であることにとどまり、version updateまで必要でない場合がほとんどですが
version updateが必要と判断される場合はその時点でupdate先ESXi と現AOSの整合性確認を行いましょう ( Nutanix ←→ ESXi )。
4. 環境全ての大幅な刷新が必要な場合
この場合はご購入の筐体ベンダーへ相談いただく事も選択肢に入りますが、
個人で確認を行う場合はNutanix AOSをベースにご確認いただくことをお勧めします。
理由として、NutanixのSupport Life MatrixがESXiに比べ短めに設定されている事が挙げられます。
また、可能な限りESXiのバージョンはその時点で最新としておくことをお勧めします。
(前提として、いつであっても原則すべて最新バージョンであることが推奨ですが...)
毎回Nutanix AOSが定める一番古いバージョンのESXiを使用していると、次回NutanixのEOSLが迫ってきたときにちょこちょこと環境全体のアップデートが必要となる可能性が高いです。
Nutanix AOSのローリングアップデートだけであれば環境の停止は必要無いため（ESXiも可能ですがESXiの1ノード欠けは発生）、
ESXiを古いバージョンで使用して毎回AOSに合わせてESXiのアップデートをしていると
かえって停止時間・メンテナンス工数の増加に繋がります。
Nutanix社のEOSL Information
http://download.nutanix.com/misc/AOS_EOL/AOS_EOL.pdf
vmware社のEOSL Information
ESXiとFirmwareの整合性確認について
ESXiそのものの整合性についてはNutanix環境か否かは関係なく、純粋にvmware社の定めるCompatibility Matrixに沿っていれば問題ありません。
(あくまで相関は ESXi ←→ Hardware であるため)
ご存知の方も多いと思いますがURLは以下となります。
https://www.vmware.com/resources/compatibility/search.php
製品カテゴリ：Sytems / Serversの状態ですと多くの場合筐体ならびにBIOSのHITのみとなりますので
必要に応じてIO Devicesなど他項目から確認しましょう。
以下は検索の一例となります。
NSXやHorizonなどのアップデートに伴い確認する場合
この場合ですが、Nutanixが見ているのはあくまでESXiのため、NSXやHorizonの整合性確認についてはNutanix AOSの考慮は必要ありません。
例えばHorizon View Connection Serverのアップデートを実行する場合でも、
ESXiに変更が無ければNutanixを考慮する必要はありません。
以上、NutanixとESXi, Hardwareの関係についてでした。
Kubernetes環境におけるNSX Container plug-inの導入について
NSX Container Plug-inの導入手順
Kubernetes + NSX-T環境におけるPlug-inの導入については
最初にZIPファイルをダウンロードする必要があります。
各種ドキュメントにURLが貼られていないので入手方法に迷われる方も多いと思います(私もその一人でした)。
色々検索ワードを変えてみること15分、アッサリmy vmwareのリンクがHITしましたので同じような方のためにURLを記載しておきます。
(以下はNSX-T 2.5.1用となります。)
NSX Container Plugin
ダウンロードされるファイルについて
上記からダウンロードすると1GB程度のZIPファイルが保存されます。
解凍すると総計2GB弱程度でした。
こちらのファイルを直接k8s nodeへ送ってunzipコマンド叩いてOS上で解凍作業を実行しても問題ないですが
不必要なファイルをmasterへ送りたくない！という方は別途管理端末で解凍し、SCP等でk8s環境へ送付してもいいかと思います。
以下、管理端末で解凍すると...
フォルダをクリックして展開すると以下フォルダが表示されます。
今回はOpenshift環境ではないのでそのまま"Kubernetes" フォルダへ進んでいきましょう。
Kubernetes フォルダ配下は以下。
ここから先はKubernetesがUbuntu / RHELどちらで構成されているかにより使用ファイルが変わります。
先述したようにZIPファイルをそのままk8s環境へ送付すると、必ず半分は不必要なファイルを送ってしまっている...ということになります。
送付先のOS上で不要ファイルを削除しても勿論問題ありませんが、本番環境でのヒューマンエラーに関する芽はできるだけ摘んでおきたいですね。
なおTARファイルはdocker loadコマンドで読み込ませるイメージのため、tarファイルのままk8s環境に送付しましょう。
ちなみにyamlファイルについて、導入前に覗いておくことをお勧めします。
（読まずにkubectl applyする方は稀かと思いますが...）
ドキュメントに導入後の追加項目が詳細に記述されていないですが、yamlファイルがそのまま閲覧可能ですので事前確認しておかない手は無いです。
以下抜粋。
実際は非常に多くのKind定義がされております。
以下公式ドキュメントにも記述がありますが
細かい作業を省いてざっくり手順分けすると以下の作業工程になります。
1. ファイルのダウンロード
2. tarファイルイメージをdocker loadで読み込ませる
3. yamlファイルをapplyする
導入後の状態について
上記のようにClusterRole / ClusterRoleBindなど非常に多数の追加項目があるためすべてご紹介はできませんが、一部導入後の状態について以下のような状態となります。
apparmorのサービス稼働状況：
Namespaceの作成状況：
(nsx-systemが新規作成されています。)
ダウンロードしたyamlファイル103行目で定義されているように、デフォルトでは"nsx-system"固定です。
PodやDeploymentなどの作成状況：
"nsx-ncp" と命名されたDeployment / nsx-node-agentのDaemonsetが確認され、
それぞれPodの形で動作している状態です。
configmapも同様：
なお互換性についてですが、Release Noteに記述がありますのでこちらも必ず事前に確認しておきましょう。
VMware社がProject Pacificに力を入れている事はvmworld / vForumでもひしひしと伝わってきましたので
広く公式ローンチがされるであろう将来のリリースに備えて、NSX-Tそのものの導入だけでなく、on Kubernetesでの各種導入・アップデートについても追いかける必要がありますね。
