これも「参考情報はいくつかあるけど、設定に苦労する」シリーズです。
vCenterのデータストア（VMFSやNFSなど）をKubernetesのPVCとして直接使用する手順を紹介します。
はじめに
そもそも何を言ってるか
Kubernetes上で動作させるコンテナ（Pod）を削除すると、Pod内のデータも全て消えてしまいます。ログやDBのデータなどは消えてしまうと困るので、Pod外の記憶領域をPodにマウントするのが一般的です。
その永続記憶領域をPV(Persistent Volume)と呼び、このボリュームをPodの間で抽象化させてる仕組み（Kubernetesのリソース）をPVC(Persistent Volume Claim)と呼びます。
そんな細かい話はどうだって良くて、PVがPodに付ける外部領域だと思えば良い。
で、今回は、vCenterのデータストアの中のファイルシステム（vmfsとかnfsとか）もPVとして利用できるという話です。
具体的には、こんな感じになります
今回紹介する設定が完了すると、こんな事ができるようになります。
例えば、以下のmanifestでPVCを作ったとします。
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc-datastore2
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi上記をkubectl apply -fしてみます。（ファイル名はどうだっていい）
[root@master-prod sample]# kubectl apply -f pvc-datastore2-nosc.yaml
persistentvolumeclaim/pvc-datastore2 createdすると、以下の画像のように、自動的にvCenterに仮想ディスクが作られます。
データストアの中を見ると、kubevolsというフォルダの中に仮想ディスクが作られてるのが確認できます。
Kubernetes上にもPVCが出来上がっています。
[root@master-prod sample]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-datastore2 Bound pvc-a3370425-0f70-42a5-b716-d5e093090de2 2Gi RWO fast 3m9sこれを使用するPodを作ります。
kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: nginx
volumeMounts:
- mountPath: "/var/www/html"
name: mypd
volumes:
- name: mypd
persistentVolumeClaim:
claimName: pvc-datastore2Podを作ります。
[root@master-prod sample]# kubectl apply -f pod-withpvc.yaml
pod/mypod createdすると、Podを割り当てたノードのホストVMに対し、前述で作成したPVCが自動的に割り当てられます。
今回はnode1のホストVMに割り当てられました。念の為、本当にmypodがnode1上で起動されたかを確認します。
[root@master-prod sample]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mypod 1/1 Running 0 2m6s 10.244.1.2 node1-prod <none> <none>mypodを削除します。
[root@master-prod sample]# kubectl delete pod mypod
pod "mypod" deletedすると、node1のVMホストから、該当の仮想ディスクが自動的にデタッチされます。
PVCも削除します。
[root@master-prod sample]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-datastore2 Bound pvc-a3370425-0f70-42a5-b716-d5e093090de2 2Gi RWO fast 8m34s
[root@master-prod sample]# kubectl delete pvc pvc-datastore2
persistentvolumeclaim "pvc-datastore2" deletedすると、vCenter内の該当仮想ディスクが自動的に削除されます。
これはデータストア内のフォルダからも確認できます。
では、設定してみる
いよいよ設定方法ですが、その前に・・・
一番躓きやすいのは「vCenter側の作業」
だと感じました。
今回の作業の大まかな流れは
- vCenter側で、Kubernetesが使用するvCenterユーザを作成
- vCenter側で、「1」で使用するロールを作成
- vCenter側で、「1」・「2」で作成したユーザ/ロールをオブジェクトに設定
- vCenter側で、KubernetesのVMの細かい設定
- Kubernetesマスターの設定
- Kubernetes worker nodeの設定
となります。つまりKubernetesの使い方を知ってるだけではダメで、vCenterの知識もそれなりに必要です。で、ネットにある設定方法の殆どが「1-3」について軽くしか触れておらず、ハマる人が多いのではと推測します。
で、1-5まで終わって「いざ稼働確認や！」となって、動かなくて途方に暮れるパターンが辛い。
特に「本来あるべき、動作する状態」が作れるまでは、トラシューが大変。一度「動作する状態」が作れたら、あとは色々付け足ししたらいいだけなので。
何が言いたいかというと、まずは「管理者ユーザ」で「動作する状態」を確立することをオススメします（ラボ環境前提）。administrator@vsphere.localで設定するのです。
これだと「1-3」は省くことができるので、殆どKubernetes側の設定にフォーカスできます。
マジでvCenterの権限設定は、初めてだとややこしいからな
この手順でも、初めはadministrator@vsphere.localを使う前提で話を勧めます。
先に言っときますが、以下の手順は全てに意味があります。1つでも飛ばしたら動作しないと思ってください。
前提作業
- vCenterの設定が完了してること（私のは6.5)
- データセンターが作られてること
- Kubernetes VM(Master/Worker node)が同じフォルダに入ってること
特に最後の「VMがフォルダに入ってること」も重要です。何を言ってるかというと、こんな状態です。
「データセンター」ができていて、合計4つのKubernetesのVMが「k8s-prod」フォルダに入ってますね。
Kubernetes master/worker nodeのVM設定
vCenterにログインし、該当のVMを右クリックし「設定の編集をクリック」→「仮想マシンオプション」→「詳細」→「設定の編集」。
設定パラメータを追加し、「disk.EnableUUID」を「True」に設定。以下の画像のようになればOKです。
これを全master/worker nodeに行います。私のケース（上記の環境）では4回行うということです。
(Master)vsphere.confの作成
Masterノードにて行います。
/etc/kubernetes/vcp/ディレクトリを作成し、以下のサンプルの通りvsphere.confを作成します。
[Global]
# Global settings are defaults for all VirtualCenters defined below
user = "administrator@vsphere.local"
password = "admin password"
port = "443"
insecure-flag = "1"
[VirtualCenter "vsphere.mylab.local"]
datacenters = "House"
[Workspace] # Defines
server = "vsphere.mylab.local"
datacenter = "House"
default-datastore = "datastore2"
resourcepool-path = "HouseCluster/Resources"
folder = "k8s-prod"
[Disk] # Required...
scsicontrollertype = pvscsi“admin password”以外は、私の環境で実際に動いている構成のconfです。”admin password”には必ず自分の環境のadministrator@vsphere.localのパスワードを入れてください。
もし自分がvCenterに「administrator@vsphere.local」ユーザで「password!」とかで入ってるなら、password = の後に”password!”と入れるってこと。セキュリティ的にヤバいねー。
細かいパラメータの説明は以下を参照してください。
>>vSphere Cloud Provider Configuration
でも、動作しないと色々不安になると思うので、少々補足します。自分の環境に適宜置き換えてください。
“vsphere.mylab.local”について
これ、vCenterのFQDN名です。私の環境だとIP:192.168.1.233がvCenterで、FQDNがvsphere.mylab.localだからこうなってます。
これはKubernetes VMの/etc/hostsで名前解決しています。
ここ、”vsphere.mylab.local”じゃなっくて”192.168.1.233″でも多分大丈夫です。
要するに、このパラメータからvCenterのアクセス先を決めてる。
“House”について
これ、vCenterの世界のデータセンター名です。
“datastore2″について
これ、PVC用の仮想ディスクを作りたいvCenterの世界のデータストア名です。私の環境では”datastore1″と”datastore2″のSSDが入っていて、後者を使用したいため。
“HouseCluster/Resources”について
これ、vCenterの世界の「クラスタ名/Resources」になります。私の環境ではvCenterのクラスタ名が「HouseClouster」なので、上記となります。
別に「Resources」というオブジェクトを明示的に作ってはいません。
“k8s-prod”について
これ、Kubernetes用VMが入ってるvCenterの世界のフォルダ名です。上記で説明したとおり。
Kubeletの環境変数追記
Kubeletに上記の設定ファイルを読み込ませる為に、Kubeletの環境変数を追記します。
しかし！このやり方、時代と共に変わっていまして、しかもKubernetesの構成方法によって色々変わってくる。
なので、今回の設定で一番ややこしいと思います。
とりあえず今回は「私が紹介してる最もシンプルなKubernetesクラスタ構築方法」でのkubeadm initで素直にやった場合を照会します。
/var/lib/kubelet/kubeadm-flags.envを修正します。修正前はこんな感じなはず。
KUBELET_KUBEADM_ARGS="--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.2"これの最後に以下のように追記します。
KUBELET_KUBEADM_ARGS="--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.2 --cloud-provider=vsphere --cloud-config=/etc/kubernetes/vcp/vsphere.conf"なぜかダブルクォーテーション(“)で囲ってるから、最後の”は上記のように移動しないといかん。”はいらないと思うんだけどね・・・
Kube-APIとKube-Containerの設定ファイル修正
これは以下を修正するということです。
- /etc/kubernetes/manifests/kube-apiserver.yaml
- /etc/kubernetes/manifests/kube-controller-manager.yaml
両方修正します。
spec:containers:command配下に以下を追記します。
- --cloud-provider=vsphere
- --cloud-config=/etc/kubernetes/vcp/vsphere.confなので、例えばkube-apiserver.yamlの場合はこんな感じになるはずです。
- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
- --cloud-provider=vsphere
- --cloud-config=/etc/kubernetes/vcp/vsphere.conf同じ要領でspec:containers:volumeMountsも以下を追記します。
- mountPath: /etc/kubernetes/vcp
name: vcp
readOnly: true（くどいけど）例えばkube-apiserver.yamlの場合はこんな感じ。
volumeMounts:
- mountPath: /etc/ssl/certs
name: ca-certs
readOnly: true
- mountPath: /etc/pki
name: etc-pki
readOnly: true
- mountPath: /etc/kubernetes/pki
name: k8s-certs
readOnly: true
- mountPath: /etc/kubernetes/vcp
name: vcp
readOnly: true最後にspec:volumeに以下を追記します。
- hostPath:
path: /etc/kubernetes/vcp
type: DirectoryOrCreate
name: vcp(くどいけど)例えばkube-apiserver.yamlの場合はこうなる。
volumes:
- hostPath:
path: /etc/ssl/certs
type: DirectoryOrCreate
name: ca-certs
- hostPath:
path: /etc/pki
type: DirectoryOrCreate
name: etc-pki
- hostPath:
path: /etc/kubernetes/pki
type: DirectoryOrCreate
name: k8s-certs
- hostPath:
path: /etc/kubernetes/vcp
type: DirectoryOrCreate
name: vcp設定箇所が多くて大変？この記事を書いてる私も大変やねんで。
Worker Nodeの設定
Masterだけではなく、Worker Nodeのkubeletも修正します。私の構成では「node1/node2/nodelb」全てです。
やり方はMaster nodeと同じですが、confファイルはないので、少しシンプル。
設定前はこんな感じです。
KUBELET_KUBEADM_ARGS="--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.2"最後に少し追記します。
KUBELET_KUBEADM_ARGS="--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.2 --cloud-provider=vsphere"ここでもダブルクォーテーションの移動を忘れたらあかん。忘れたらkubeletが起動しなくなりますよ。
各ノードにUUIDをセットする
Kubernetesの世界でやります。Master Nodeだけで操作します。
公式サイトの手順だと、以下を参考。
>>Update all node ProviderID fields
これ、何をしているかというと、vCenterがKubernetes Nodeを一意に識別するUUIDを、Kubernetesの世界でセットするということです。
これ、何で必要かといいますと、Podを作成した後にPVCを割り当てたい場合、vCenterは「どのWorker NodeのVMに仮想ボリュームを割り当てたらいいか」を知る必要があるからです。つまりVPC初期作成とは全然関係なくて、Pod作成時に必要なのです。
で、運が良ければNodeに初めからUUIDが割り当てられてるらしいのですが、私はそんな環境を見たことがありません。
これは以下のコマンドで確認できます。
kubectl get nodes -o json | jq '.items[]|[.metadata.name, .spec.providerID, .status.nodeInfo.systemUUID]'パイプの後の「jq」とは、json結果をいい感じで表示してくれるツールなのですが、私の環境構成手順では入っていないので、以下のコマンドで入れておきます。
yum install epel-release
yum install jq --enablerepo=epelそろそろ疲れてきた、とか言わないでくれ。もうすぐです。
これで実際にコマンド実行してみてください。
[
"master-prod",
"vsphere://421139D7-7532-0BB0-591B-9BBC0CDD3796",
"D7391142-3275-B00B-591B-9BBC0CDD3796"
]
[
"node1-prod",
"vsphere://4211A699-7499-A35E-4E42-0E16582AA401",
"99A61142-9974-5EA3-4E42-0E16582AA401"
]
[
"node2-prod",
"vsphere://42116928-4A43-26F3-DFBB-C78F44095E3E",
"28691142-434A-F326-DFBB-C78F44095E3E"
]
[
"nodelb-prod",
"vsphere://4211C13B-7DF0-9964-D3A9-B6F6C85076E1",
"3BC11142-F07D-6499-D3A9-B6F6C85076E1"
]上のは既に全て設定が終わった後の結果です。設定前の結果を保存してなかったのです。
もしUUIDが設定してなければ、”vsphere…”が入ってないはず。というか、普通は入ってないはず。
なので、公式手順のスクリプトを使って、UUIDをセットします。普通のラボ環境だとMasterで適当にkubectlで設定すると思うので、Masterを使うとします。
すると、スクリプトでgovcを使ってるので、こちらのインストールが必要になります。適当にvspherecliとでもディレクトリ作ってgovcをwgetしてリンク貼ります。
cd vspherecli/
wget https://github.com/vmware/govmomi/releases/download/v0.20.0/govc_linux_amd64.gz
gunzip govc_linux_amd64.gz
ln -s /root/vspherecli/govc_linux_amd64 /usr/local/bin/govcgovcコマンドが使えたら、一旦安心する。
[root@master-prod manifests]# govc version
govc 0.20.0これで「あとはスクリプト実行したら自動的にUUIDがNodeに割り振られる！」となりますが、そんな簡単にはいきません。
実行するスクリプトは以下のとおりですね。（上記の公式リンクの「following script to set 」で検索してください。まぁ以下の通りです。）
#!/bin/bash
export GOVC_USERNAME='<user>'
export GOVC_INSECURE=1
export GOVC_PASSWORD='<password>'
export GOVC_URL='<server>'
DATACENTER='Coop'
FOLDER='<path>'
# In my case I'm using a prefix for the VM's, so grep'ing is necessary.
# You can remove it if the folder you are using only contains the machines you need.
VM_PREFIX='<prefix>'
IFS=$'\n'
for vm in $(./govc ls "/$DATACENTER/vm/$FOLDER" | grep $VM_PREFIX); do
MACHINE_INFO=$(./govc vm.info -json -dc=$DATACENTER -vm.ipath="/$vm" -e=true)
# My VMs are created on vmware with upper case names, so I need to edit the names with awk
VM_NAME=$(jq -r ' .VirtualMachines[] | .Name' <<< $MACHINE_INFO | awk '{print tolower($0)}')
# UUIDs come in lowercase, upper case then
VM_UUID=$( jq -r ' .VirtualMachines[] | .Config.Uuid' <<< $MACHINE_INFO | awk '{print toupper($0)}')
echo "Patching $VM_NAME with UUID:$VM_UUID"
# This is done using dry-run to avoid possible mistakes, remove when you are confident you got everything right.
kubectl patch node $VM_NAME -p "{\"spec\":{\"providerID\":\"vsphere://$VM_UUID\"}}"
done重要なのは真ん中の以下の行です。
for vm in $(./govc ls "/$DATACENTER/vm/$FOLDER" | grep $VM_PREFIX); doここでvCenterにアクセスしてUUIDをセットするVMをvCenterのフォルダでフィルタリングしてリストアップしてるんですが、「|grep $VM_PREFIX」で更にフィルタリングしてるんですよ。
例えば私のケースでは「k8s-prod」フォルダに以下のVMがあるわけです。
- k8s-master
- k8s-node1
- k8s-node2
- k8s-nodelb
この4VM全てのUUIDをセットしたいだけなので、別にgrepでフィルタリングする必要はないのですが、まぁgrepが付いてるのでVM_PREFX変数にk8sをセットしました。
で、実際にKubernetes nodeにUUIDを設定しているのは最後から2行目の以下のコードです。
kubectl patch node $VM_NAME -p "{\"spec\":{\"providerID\":\"vsphere://$VM_UUID\"}}"なので、上記をコメントアウトしたら基本的に害はなく実行できるはず。
当然自己責任やで
更に、当スクリプトはスクリプトと同じ場所にgovcがあること前提なので「.govc」と書いています。その辺を修正してみたスクリプトが以下。
#!/bin/bash
export GOVC_USERNAME='administrator@vsphere.local'
export GOVC_INSECURE=1
export GOVC_PASSWORD='password'
export GOVC_URL='192.168.1.233'
DATACENTER='House'
FOLDER='k8s-prod'
# In my case I'm using a prefix for the VM's, so grep'ing is necessary.
# You can remove it if the folder you are using only contains the machines you need.
VM_PREFIX='k8s'
IFS=$'\n'
#for vm in $(./govc ls "/$DATACENTER/vm/$FOLDER" | grep $VM_PREFIX); do
for vm in $(govc ls "/$DATACENTER/vm/$FOLDER" | grep $VM_PREFIX); do
#MACHINE_INFO=$(./govc vm.info -json -dc=$DATACENTER -vm.ipath="/$vm" -e=true)
MACHINE_INFO=$(govc vm.info -json -dc=$DATACENTER -vm.ipath="/$vm" -e=true)
# My VMs are created on vmware with upper case names, so I need to edit the names with awk
VM_NAME=$(jq -r ' .VirtualMachines[] | .Name' <<< $MACHINE_INFO | awk '{print tolower($0)}')
# UUIDs come in lowercase, upper case then
VM_UUID=$( jq -r ' .VirtualMachines[] | .Config.Uuid' <<< $MACHINE_INFO | awk '{print toupper($0)}')
echo "Patching $VM_NAME with UUID:$VM_UUID"
# This is done using dry-run to avoid possible mistakes, remove when you are confident you got everything right.
#kubectl patch node $VM_NAME -p "{\"spec\":{\"providerID\":\"vsphere://$VM_UUID\"}}"
doneGOVC_PASSWORDにはadministrator@vsphere.localを入れます。
さて、上記の実行結果が以下です。
Patching k8s-nodelb with UUID:4211C13B-7DF0-9964-D3A9-B6F6C85076E1
Patching k8s-node1 with UUID:4211A699-7499-A35E-4E42-0E16582AA401
Patching k8s-master with UUID:421139D7-7532-0BB0-591B-9BBC0CDD3796
Patching k8s-node2 with UUID:42116928-4A43-26F3-DFBB-C78F44095E3Eまず、UUID:の後のIDは、vCenterにgovcでアクセスして取得している値です。
Patchingの後の”k8s…”は、vCenterにgovcでアクセスして取得したVM名です。
そのVM名に対してUUIDをセットしようとしています。
私の環境では「vCenter上のVM名」と「Kubernetes上のノード名」は同じではありません。なのでこのままだとUUIDの設定に失敗します。
[root@master-prod vspherecli]# kubectl get node
NAME STATUS ROLES AGE VERSION
master-prod Ready master 2d23h v1.18.3
node1-prod Ready <none> 2d23h v1.18.3
node2-prod Ready <none> 2d23h v1.18.3
nodelb-prod Ready <none> 2d22h v1.18.3例えばMater Nodeの場合、vCenter上のVM名は「k8s-master」で、Kubernetes上のノード名は「master-prod」です。
なので、こちらを設定する場合、正しいコマンドは
kubectl patch node master-prod -p "{\"spec\":{\"providerID\":\"vsphere://421139D7-7532-0BB0-591B-9BBC0CDD3796\"}}"となります。
なので、vCenter上のVM名とKubernetes上のノード名が違う場合、上記のように適宜変更して、手動でkubectlで設定したほうが安全かと思います。
設定した結果は上記に書きましたが、一応同じものを以下に残します。
kubectl patch node nodelb-prod -p "{\"spec\":{\"providerID\":\"vsphere://4211C13B-7DF0-9964-D3A9-B6F6C85076E1\"}}"
kubectl patch node node1-prod -p "{\"spec\":{\"providerID\":\"vsphere://4211A699-7499-A35E-4E42-0E16582AA401\"}}"
kubectl patch node node2-prod -p "{\"spec\":{\"providerID\":\"vsphere://42116928-4A43-26F3-DFBB-C78F44095E3E\"}}"
kubectl patch node master-prod -p "{\"spec\":{\"providerID\":\"vsphere://421139D7-7532-0BB0-591B-9BBC0CDD3796\"}}"
[root@master-prod vspherecli]# kubectl get nodes -o json | jq '.items[]|[.metadata.name, .spec.providerID, .status.nodeInfo.systemUUID]'
[
"master-prod",
"vsphere://421139D7-7532-0BB0-591B-9BBC0CDD3796",
"D7391142-3275-B00B-591B-9BBC0CDD3796"
]
[
"node1-prod",
"vsphere://4211A699-7499-A35E-4E42-0E16582AA401",
"99A61142-9974-5EA3-4E42-0E16582AA401"
]
[
"node2-prod",
"vsphere://42116928-4A43-26F3-DFBB-C78F44095E3E",
"28691142-434A-F326-DFBB-C78F44095E3E"
]
[
"nodelb-prod",
"vsphere://4211C13B-7DF0-9964-D3A9-B6F6C85076E1",
"3BC11142-F07D-6499-D3A9-B6F6C85076E1"
]
[root@master-prod vspherecli]#以上で設定は終了です。お疲れさまでした！
最後のスクリプト解説が想像以上に時間かかった・・・やってる時は一瞬やのに・・・
実際に使ってみる
冒頭で使用結果を伝えたため、詳細は省きますが、実際に動作確認したmanifestの共有も含めて照会します。
まずはKubernetesノード(Master/worker全て)を再起動します。恐らくsystemctl daemon-reloadでもいけますが、ラボ環境なので手っ取り早く。
その後、まずはstorage classを作ります。
[root@master-prod sample]# cat sc-datastore2-policy.yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: fast
provisioner: kubernetes.io/vsphere-volume
parameters:
datastore: datastore2nameは何でもいいです。どこかのサンプルをそのまま使ってます。
kubectl apply -f sc-datastore2-policy.yamlで適用します。
[root@master-prod sample]# kubectl get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
fast kubernetes.io/vsphere-volume Delete Immediate false 3h5mできてますね。
次に、いよいよPVCを作ります。
[root@master-prod sample]# cat pvc-datastore2.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc-datastore2
annotations:
volume.beta.kubernetes.io/storage-class: fast
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2GiこれでPVCができます。後は冒頭で照会したとおりです。
ちなみに、この状態では毎回「annotations」にstorage-class名を入れないといけなくて若干面倒なので、この(fast)storage classをデフォルトにも設定できます。
kubectl patch storageclass fast -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'これで、デフォルトになりました。
[root@master-prod sample]# kubectl get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
fast (default) kubernetes.io/vsphere-volume Delete Immediate false 3h7mこれで、annotationなしでもPVCが作れます（自動的にfastを使ってる）。
[root@master-prod sample]# cat pvc-datastore2-nosc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc-datastore2
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Giこの後、administrator@vsphere.localの使用をやめよう
ここまででvCenterデータストアの仮想ボリュームをPVCとして利用できることが実証できました。
後はセキュリティを強化する意味でもadministratorではない別のユーザで再設定しましょう。
とは言っても、ここまで来たら、公式の設定手順を参考にしていけるはずです。
Role名やユーザ名は何でもいいです。ただ、各オブジェクトに設定する時に間違えないように。あと、vsphere.confの修正も忘れずに（これにadminパスワードが入ってるのがまずいので）。
更にいうと、vsphere.confのクレデンシャル情報をKubernetesのシークレットとして設定する方がいいでしょうね。
まとめ
できるだけステップバイステップで設定方法を解説してみました。
想像以上に面倒くさかったです。
コメント