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
上記コマンドを入力すると、手順1番で作成した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の設定を進めていきます。