はい、それでは本日も始めましょう！
（・・と、その前に報告があります。この後、Supervisorクラスタに疎通できない現象が発生し、HAProxyとSupervisorクラスタを作り直しました。原因は不明ですが、ネットワーク設定を変更したら上手くいったので、その時のパラメータを共有します。 Day18とDay19で、(2020年12月21日更新)となっている箇所を、ご確認下さい。）
#vSphere with Tanzu用のGWと踏み台作成
「CLIツールへのリンク」の右下にある「開く」を押し、ダウンロード画面に遷移します。
・・・と、思ったけど繋がらない。それもそのはず、リンク先がWorkloadネットワーク(172.18)になっている。。このローカルMacから到達できるよう設定してないので、当然アクセス出来ません。
なお、この「172.16.100.1」は、Supervisorクラスタに割り当てられたVirtualIPです。管理ネットワーク側のSupervisorクラスタのアドレスである、「192.168.5.211」にアクセスすることで、目的のページには辿り着けました。
要件的には、開発者は「172.18.」のネットワークに到達できるべきなので、GWサーバを作成してあげます。また踏み台も、vSphere with Tanzu用にまっさらな環境で検証したいので、「nested-bastion02」を新たに作成します。
基本的にはどちらも、Day13の踏み台サーバデプロイの時と同じ要領です。
違いとしては、GWサーバには、「172.18.X.X」にアクセス可能なネットワークを追加しました。
各サーバは、以下のIPで設定してみます。
- nested-bastion02 : 192.168.5.44
- ubuntu-gw : 192.168.5.253 / 172.18.0.1
GWサーバ設定
まずIPアドレスは、以下のように増やします。
$ ip a
# 編集対象のインターフェイス名を確認。私の場合は「ens192とens224」だった。
$ sudo vi /etc/netplan/99_config.yaml
# 編集開始。ご自身の環境に合わせて書き換えて下さい
network:
version: 2
renderer: networkd
ethernets:
ens192:
dhcp4: false
dhcp6: false
addresses: [192.168.5.253/24]
gateway4: 192.168.5.1
nameservers:
addresses: [192.168.5.1, 8.8.8.8, 8.8.4.4]
ens224:
dhcp4: false
dhcp6: false
addresses: [172.18.0.1/24]
gateway4: 172.18.0.1
nameservers:
addresses: [8.8.8.8, 8.8.4.4]
# 編集ここまで
$ sudo netplan apply
# 設定が反映されると、今までのIPアドレスでは通信できなくなるので、ログインし直す
続いて、以下のようにGWを設定します。
# ip_forwardがコメントされてるので、コメントを取る
$ sudo vi /etc/ufw/sysctl.conf
net/ipv4/ip_forward=1
# FOWARD_POLICYを"DROP"から"ACCEPT"に変える
$ sudo vi /etc/default/ufw
#DEFAULT_FORWARD_POLICY="DROP"
DEFAULT_FORWARD_POLICY="ACCEPT"
$ sudo ufw logging low
$ sudo ufw allow ssh
$ sudo ufw allow 53 #(DNS)
$ sudo ufw allow 443 #(HTTPS)
$ sudo ufw allow 80 #(HTTP)
$ sudo vi /etc/ufw/before.rules
# 編集ここから。COMMIT行の直前あたりに追加。
# NAT setting
*nat
-F
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.168.5.0/24 -o eth0 -j MASQUERADE
# 編集ここまで
COMMIT
#ufwの適用
$ sudo ufw enable
# 以下のエラーでDNSタイムアウトを起こすようになったので対策
# sudo: unable to resolve host ubuntu-gw: Temporary failure in name resolution
sudo sh -c 'echo 127.0.0.1 $(hostname) >> /etc/hosts'
###ルータ側の設定
※まったくvSphere関係ないですｗ
うちのルータの経路設定。192.168.5.253に作ったGWサーバを経路に指定することで、172.16.0.0/24のネットワークが見えるようになりました
ご参考まで。。
これで、やっとCLI Toolsに正しくアクセスできました！
Kubernetes CLI Toolsのインストール
「SELECT OPERATING SYSTEM」で「Linux」を選択し、「CLI PLUGIN LINUX」と「Checksum CLI plugin Linux」をダウンロードします。
ついでに、「vSphere Docker Credential Helper」も、ダウンロードしておきます。Checksumは同名のようなので、CLI toolsの方のファイル名を「sha256sum-cli.txt」にリネームするなどして、対応しましょう。
続いてアップロード
$ scp ~/Downloads/vsphere-*.zip ubuntu@192.168.5.44:~
vsphere-docker-credential-helper.zip 100% 7568KB 3.3MB/s 00:02
vsphere-plugin.zip 100% 28MB 3.1MB/s 00:09
$ scp ~/Downloads/sha256sum* ubuntu@192.168.5.44:~
sha256sum-cli.txt 100% 85 22.5KB/s 00:00
sha256sum.txt 100% 103 24.0KB/s 00:00
インストール
# チェックサム確認
$ ls
sha256sum-cli.txt sha256sum.txt vsphere-docker-credential-helper.zip vsphere-plugin.zip
$ shasum --algorithm 256 --check sha256sum-cli.txt < vsphere*-plugin.zip
vsphere-plugin.zip: OK
$ shasum --algorithm 256 --check sha256sum.txt < vsphere-docker-credential-helper.zip
vsphere-docker-credential-helper.zip: OK
$ rm sha256sum*
# unzipコマンドのインストール
$ sudo apt update
$ sudo apt install unzip
# kubectl, docker-credentialコマンドの設置
$ unzip vsphere-plugin.zip
Archive: vsphere-plugin.zip
creating: bin/
inflating: bin/kubectl-vsphere
inflating: bin/kubectl
$ unzip vsphere-docker-credential-helper.zip
Archive: vsphere-docker-credential-helper.zip
creating: bin/
inflating: bin/docker-credential-vsphere
$ sudo mv bin/* /usr/local/bin/
はい、これで設置完了。
vSphere with Tanzuへのログイン
まずは、SupervisorクラスタにSSOログインしてあげる必要があります。先ほどの、「172.18.0.208」を指定してあげましょう。
$ kubectl vsphere login --server=172.18.0.208 --insecure-skip-tls-verify
Username: devops@vsphere.local # @vsphere.local をつけるのを忘れずに
Password: # 事前に設定したパスワードを入力
Logged in successfully.
You have access to the following contexts:
172.18.0.208
tkgs-dev
If the context you wish to use is not in this list, you may need to try
logging in again later, or contact your cluster administrator.
To change context, use `kubectl config use-context <workload name>`
これでSSOログインは完了です。簡単ですね。続いて、contextの操作。複数のSupervisor Namespaceがある場合、contextを切り替えることで、対象クラスタを指定します。
172.18.0.208がSupervisorクラスタで、tkgs-devは、今回作成したSupervisor Namespaceです。
# コンテキスト一覧の表示。「*」は、現在利用中のコンテキスト
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
172.18.0.208 172.18.0.208 wcp:172.18.0.208:devops@vsphere.local
* tkgs-dev 172.18.0.208 wcp:172.18.0.208:devops@vsphere.local tkgs-dev
# コンテキストの指定は、use-context
$ kubectl config use-context tkgs-dev
Switched to context "tkgs-dev".
TKCのデプロイ
まずは、サンプルファイルをGitHubから落として、ファイルを編集しましょう。
$ wget https://raw.githubusercontent.com/vsphere-tmm/vsphere-with-tanzu-quick-start/master/manifests/tkc.yaml
# (出力経過は省略)
2020-12-21 15:44:36 (8.46 MB/s) - ‘tkc.yaml’ saved [555/555]
$ vi tkc.yaml
# 4箇所あるstorageClassを今回作成した「k8s-dev-storage-policy」に書き換える
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
name: tkc-1
spec:
distribution:
version: v1.18
topology:
controlPlane:
class: guaranteed-small
count: 1
storageClass: k8s-dev-storage-policy
workers:
class: guaranteed-small
count: 1
storageClass: k8s-dev-storage-policy
settings:
storage:
classes: ["k8s-dev-storage-policy"] #Named PVC storage classes
defaultClass: k8s-dev-storage-policy #Default PVC storage class
これをデプロイしてみましょう！
$ kubectl apply -f tkc.yaml
# 台数にもよるが、数分待つと出来上がる。初回は時間かかるかも・・
こちらもTKGに負けず劣らず簡単ですね！
vCenter上に、蜂の巣のようなマークのTKCが出来上がり、control-planeとworkersが増えました！
次は、別途TKCにSSOログインしてあげる必要があります。ここら辺はシームレスに切り替えられるTKGより面倒ですが、TKCをデプロイする人と利用する人が別に居る想定なのかも。。
# TKCへのログイン方法
$ SC_IP=172.18.0.208
$ NAMESPACE=tkgs-dev
$ kubectl vsphere login --server=$SC_IP --tanzu-kubernetes-cluster-name tkc-1 --tanzu-kubernetes-cluster-namespace $NAMESPACE --insecure-skip-tls-verify
# (以下省略)
はい、TKCにログインできました。状態を見ていきましょう。
# tkc-1が増えたことが確認できます。
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
172.18.0.208 172.18.0.208 wcp:172.18.0.208:devops@vsphere.local
* tkc-1 172.18.0.209 wcp:172.18.0.209:devops@vsphere.local
tkgs-dev 172.18.0.208 wcp:172.18.0.208:devops@vsphere.local tkgs-dev
# ノードの確認
$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
tkc-1-control-plane-2x6vd Ready master 29m v1.18.5+vmware.1 172.18.0.132 <none> VMware Photon OS/Linux 4.19.129-1.ph3-esx containerd://1.3.4
tkc-1-workers-kmdnp-758889fcc7-5vdx4 Ready <none> 20m v1.18.5+vmware.1 172.18.0.133 <none> VMware Photon OS/Linux 4.19.129-1.ph3-esx containerd://1.3.4
# 各リソースの確認
ubuntu@nested-bastion02:~$ kubectl get all -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system pod/antrea-agent-m8lpg 2/2 Running 0 21m
kube-system pod/antrea-agent-n458z 2/2 Running 0 30m
kube-system pod/antrea-controller-846bd89cc6-tvjms 1/1 Running 0 30m
kube-system pod/coredns-7df5887866-ctbzr 1/1 Running 0 30m
kube-system pod/coredns-7df5887866-jmnsh 1/1 Running 0 30m
kube-system pod/etcd-tkc-1-control-plane-2x6vd 1/1 Running 0 29m
kube-system pod/kube-apiserver-tkc-1-control-plane-2x6vd 1/1 Running 0 28m
kube-system pod/kube-controller-manager-tkc-1-control-plane-2x6vd 1/1 Running 1 28m
kube-system pod/kube-proxy-2sl4m 1/1 Running 0 21m
kube-system pod/kube-proxy-x2krb 1/1 Running 0 30m
kube-system pod/kube-scheduler-tkc-1-control-plane-2x6vd 1/1 Running 1 29m
vmware-system-auth pod/guest-cluster-auth-svc-j6qgt 1/1 Running 0 29m
vmware-system-cloud-provider pod/guest-cluster-cloud-provider-584cffdfb5-fbjtp 1/1 Running 1 30m
vmware-system-csi pod/vsphere-csi-controller-66b875d646-58wmr 6/6 Running 0 30m
vmware-system-csi pod/vsphere-csi-node-5m8d6 3/3 Running 0 21m
vmware-system-csi pod/vsphere-csi-node-qdvgw 3/3 Running 0 30m
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 30m
default service/supervisor ClusterIP None <none> 6443/TCP 30m
kube-system service/antrea ClusterIP 10.101.205.71 <none> 443/TCP 30m
kube-system service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 30m
NAMESPACE NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
kube-system daemonset.apps/antrea-agent 2 2 2 2 2 kubernetes.io/os=linux 30m
kube-system daemonset.apps/kube-proxy 2 2 2 2 2 kubernetes.io/os=linux 30m
vmware-system-auth daemonset.apps/guest-cluster-auth-svc 1 1 1 1 1 node-role.kubernetes.io/master= 30m
vmware-system-csi daemonset.apps/vsphere-csi-node 2 2 2 2 2 <none> 30m
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
kube-system deployment.apps/antrea-controller 1/1 1 1 30m
kube-system deployment.apps/coredns 2/2 2 2 30m
vmware-system-cloud-provider deployment.apps/guest-cluster-cloud-provider 1/1 1 1 30m
vmware-system-csi deployment.apps/vsphere-csi-controller 1/1 1 1 30m
NAMESPACE NAME DESIRED CURRENT READY AGE
kube-system replicaset.apps/antrea-controller-846bd89cc6 1 1 1 30m
kube-system replicaset.apps/coredns-7df5887866 2 2 2 30m
vmware-system-cloud-provider replicaset.apps/guest-cluster-cloud-provider-584cffdfb5 1 1 1 30m
vmware-system-csi replicaset.apps/vsphere-csi-controller-66b875d646 1 1 1 30m
TKGとの違いとして、「guest-cluster-auth-svc」というサービスの存在を確認することができます。
リソース魚拓
TKCは、先ほど撮ったので割愛しますが、↓のControlPlaneやWorkerに比べて消費量が多いようなので、Supervisorクラスタも込みなのかも。
###ControlPlane
メモリが1GB程度消費しますね。ストレージは結構必要。
###Worker
ストレージのみ消費。
###その他
Supervisorクラスタより先は、割愛します。。昨日、TKGのTKCを消したり、コンテンツライブラリを、「すべてのライブラリコンテンツをすぐにダウンロード」から、「必要な場合にのみライブラリコンテンツをダウンロード」に変更したので、合計リソースが変わってしまいました。。
本日は終了です！ついに、vSphere with Tanzuが使えるようになりましたね。
ちょっとトラブルがあり、スケジュールが遅れてきた。。ここから巻き返します！