SupervisorServiceとはvSphereのSupervisorから提供するアプリケーションのことで、yamlをvSphereに渡すことで色々なカタログ化されたアプリケーションをSupervisorクラスタ上に展開できるようになる。
現時点ではこちらによると
- vDPP
- Velero
- Cert-Manager
- Harbor
- Contour
- ExternalDNS
が利用できる模様。
ここでは公式ドキュメントに従ってHarborをSupervisorServiceとして入れた時の作業をメモ化する。
なお、ここでの前提条件として以下があるものとする。
- vSphere 8.0u1以降
- NSX-Tで有効化したSupervisorCluster
メモの流れとしては以下となる
- Contourのインストール
- Harborのインストール
- 動作確認コンテナイメージとして
3.1. dockerコマンドで確認
3.2. Supervisorクラスタから確認
3.3. Tanzu Kubernetes Clusterから確認
Contourのインストール
Supervisor Services CatalogからContourのyamlをDownloadする。
[ワークロード管理]->[名前空間]->[サービス]に飛び、「サービスの新規追加」の追加ボタンをクリックし、yamlを追加する。
なお、vSphereが8.0aとかだと以下のようなエラーが出る。
ID contour.tanzu.vmware.com のスーパーバイザー サービスの作成は許可されていません。許可リストファイル /etc/vmware/wcp/supervisor-services-allow-list.txt で定義されているサービス ID のみが許可されます。
もしこれが表示された場合はvSphereのバージョンが8.0u1以降になっていることを確認する。
問題ない場合、以下のように正常に登録できた旨が表示される。
その下の方にcontourが表示されるので、こちらからインストールする。本来はここで設定変更するが、インストール後の設定変更を試してみたかったので、一旦設定はデフォルトで進める。
なお、スーパーバイザーがNSXと連携できていない場合、以下のようにスーパーバイザーがゼロとなり、インストール先が選べない。
しばらく待つと、ContourがvSphere Podとして起動する。
$ kubectl get all -n svc-contour-domain-c8
NAME READY STATUS RESTARTS AGE
pod/contour-8c96bbf96-55ltq 1/1 Running 0 3m41s
pod/contour-8c96bbf96-9cj6s 1/1 Running 0 3m41s
pod/envoy-qbnvn 2/2 Running 0 3m35s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/contour ClusterIP 10.96.0.248 <none> 8001/TCP 3m45s
service/envoy NodePort 10.96.0.241 <none> 80:30388/TCP,443:30661/TCP 3m45s
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/envoy 1 1 1 1 1 <none> 3m46s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/contour 2/2 2 2 3m45s
NAME DESIRED CURRENT READY AGE
replicaset.apps/contour-8c96bbf96 2 2 2 3m45s
kubectl get allの結果を見ると分かるが、Envoyがtype: Nodeportで起動している。
これは先程設定せずにContourをデプロイしたためだ。
これをtype: LoadBalancerに変更して、Envoyが外部に公開するIPアドレスを持つようにする。
[ワークロード管理]からスーパーバイザーを選択し、[構成]->[スーパーバイザーサービス]で、contourを選択して[編集]をクリックする。
YAMLサービス構成というYAML入力フォームが出てくるので、SupervisorServicesのContourのページにあるvalues for v1.18.2のyamlを取得して、内容を追記する。
（元の記述は残しておく）
追記してOKを押すと、自動で設定がクラスタ側に反映され、Envoyも自動で再起動する。
$ kubectl get svc -n svc-contour-domain-c8
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
contour ClusterIP 10.96.0.248 <none> 8001/TCP 21m
envoy LoadBalancer 10.96.0.241 10.220.14.228 80:30388/TCP,443:30661/TCP 21m
なお、WebUIからもExternal IPは取得できる。
Harborのインストール
同じ手順でHarborもインストールする。
Harborのyaml(本体とvalues.yaml)をDownloadする。
ダウンロード後、values.yamlを変更する。hostnameとstorageClassだけ修正してデプロイする。
hostnameはドメインを持っていない人は、sslip.ioを利用するとよい。ここではssharbor.10-220-14-228.sslip.ioを指定した。
パスワード等、他のパラメータも変えたい人はここで変えておく。なお変更禁止のパラメータもあるので、公式手順を確認した上で変更すること。
変更後、Contourと同じようにサービスにHarborを追加してスーパーバイザーへのインストールからインストールする。
インストール完了後、Supervisor Namespaceが作成されてPodが展開される。
$ kubectl get pod -n svc-harbor-domain-c8
NAME READY STATUS RESTARTS AGE
harbor-core-78f5b4bf78-z9t79 1/1 Running 0 107m
harbor-database-0 1/1 Running 0 116m
harbor-exporter-6d85f4f9d8-bdzjm 1/1 Running 0 116m
harbor-jobservice-79dbdb6666-j9hqd 1/1 Running 0 116m
harbor-portal-6cdcbc6f7-bg6dr 1/1 Running 0 116m
harbor-redis-0 1/1 Running 0 116m
harbor-registry-6c48cb4d5-cs2xq 2/2 Running 0 116m
harbor-trivy-0 1/1 Running 0 116m
Harborへアクセス後、ユーザ名admin、パスワードHarbor12345でログインすることができる。
組み込み版Harborと違って表示項目の多いHarborになっていることが分かる。
なお、インストール後にアクセス先のFQDNを取得する方法が公式に提供されていない気がする（httpproxyリソースは通常の方法では取得不可）。
アクセス先を忘れてしまったら、SupervisorServiceの編集ボタンから取得するのが現時点では解になりそう。
Harborの利用
dockerから利用する
試しに適当なイメージをpushしてみる。
まず、Harborの証明書を取得する。ログインして[Configureation]->[System Settings]からRegistry Root Certifacateの横のDownloadを選択して証明書をDownloadする。
証明書をContainerランタイムに読み込ませる。Linux+Dockerの場合は以下。環境によって異なるため注意。
export HARBOR_HOST=ssharbor.10-220-14-228.sslip.io
sudo mkdir /etc/docker/certs.d/${HARBOR_HOST}
sudo mv ca.crt /etc/docker/certs.d/${HARBOR_HOST}
sudo systemctl restart docker
イメージをpushする。
docker pull nginx
docker tag nginx ssharbor.10-220-14-228.sslip.io/library/nginx
docker login $HARBOR_HOST -u admin -p Harbor12345
docker push ssharbor.10-220-14-228.sslip.io/library/nginx
特にミスがなければpushに成功する。LibraryはPublicだが、docker loginしていないとpushできなかった。ここでのPublicはどうやら子のTanzu Kubernetes Cluster(TKC)に対するPublicの模様。
ついでにpushしたイメージにTrivyよる脆弱性スキャンも実行してみた。
問題なく利用できた。
Supervisor Clusterから利用する
クラスタのノードにHarborの証明書が入っていないため、そのままだと利用できない。
公式ドキュメントに、kube-systemのConfigMapのimage-fetcher-ca-bundleを編集するよう書いてあるのでやってみる。
以下のコマンドでConfigMapを編集する。
kubectl edit cm -n kube-system image-fetcher-ca-bundle
editで開くと、元々あった証明書は崩れた形式で表示されたので、念の為整形して、シングルクォートで囲まれてたのも外して追記した。
以下の、2番め以降の証明書がHarborの証明書となる。
data:
ca-bundle: |
-----BEGIN CERTIFICATE-----
MIIC/jCCAeagAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
cm5ldGVzMB4XDTIzMDQxNzAwNTgwNVoXDTMzMDQxNDAwNTgwNVowFTETMBEGA1UE
AxMKa3ViZXJuZXRlczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANjm
zFSMcXuG6wR5YEvs9NdQEMQsXiplQMrYkIBEd2XmO5O8MyDxpQ5ji4ILt6XbyDS8
0a4W+w0t7/xmosqvYCbWvvbANyUmlad2PDLRPQWtltZKp37Rmkqf/udnMnnpOw2E
bTHZImagQea0iipzlntEOLNbsbBH3RReLnqvL5EuLHCK/NwEF7lo+gDBh3BwPq7C
h+91h424VBOUHh1V4UyeKnZHmVxpHoNAHTbhX2LeZH57LP8fa4jQjMZ+RFgy54J4
2s1b2U16vqSVhDZg+O9PLwR/XSa95eldeCOsQqMb7d5yfGer6elhzI37eBdLumfE
uNjn+D443xuXW5jPxHECAwEAAaNZMFcwDgYDVR0PAQH/BAQDAgKkMA8GA1UdEwEB
/wQFMAMBAf8wHQYDVR0OBBYEFPkHmBMrp4KvFMG5PMIsSN6vDR/iMBUGA1UdEQQO
MAyCCmt1YmVybmV0ZXMwDQYJKoZIhvcNAQELBQADggEBACvl7wfdOrcR0mK9FcP8
/KN/IFZQBboh3oNb0TVdDEzpmIt18b8T7MA23IikauD2H/2S3iX6sgULL3mL2vS/
ijeZlRMdtgFccAUeWTs3jCLytSDIiOE5q9IWZ0U9PsNZNvMpig38GxxuVwn1Z/4z
WyNY1r+wCHeHeVHIm+eisIJSfFTWAWkAA1yHHXjRUIRFPVi1psrbrL1Qs1XsPxAa
35LbQ/L8SsSVW/50ZZEFnLVR0Wf15lC7dLAbiqWc0hd+6WWnk9GqDS0+DXjRWoJg
L7ILsvzKudtmDJpUASx+tsxwc6eQCkIMFtLlHb3b5b/pBQLCmq0TzNtDs/O9dJYi
4oM=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDKTCCAhGgAwIBAgIRAN2d+1dEquQvMvzQtyudC+AwDQYJKoZIhvcNAQELBQAw
FDESMBAGA1UEAxMJSGFyYm9yIENBMB4XDTIzMDUwMTA1NDgzNFoXDTMzMDQyODA1
NDgzNFowFDESMBAGA1UEAxMJSGFyYm9yIENBMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEA4665pHHeG9aiJeujXkc+xTTnGIRucKdG9ZfJk1BdOzzszHVp
OrOKVdSU4YnqrPsc1D1vOoFn57whfMURH+A2qbef5nTG2tym4Gx06AQRvR5EUNVQ
：（省略）
これを保存して先程pushしたイメージを起動してみる。
$ kubectl run --image ssharbor.10-220-14-228.sslip.io/library/nginx -n ns1 nginx
pod/nginx created
$ k get pod -n ns1
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 45s
問題ないようだ。何かしらのController系のPodの再起動なども不要だった。
Tanzu Kubernetes Cluster(TKC)から利用する
Harborがいるスーパーバイザークラスタから作成されたTKCであれば、新規・既存関係なく設定不要で利用できる。
先程pushしたイメージを起動してみる。
$ kubectl run --image ssharbor.10-220-14-228.sslip.io/library/nginx -n default nginx
pod/nginx created
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 7s
こちらも問題なさそう。
おまけ：SupervisorServiceの中身
Contourのyamlの中はKubernetesリソースとなっており、kind: Packageとkind: PackageMetadataを利用している。
$ grep ind contour.yml
kind: Package
kind: PackageMetadata
またvalues.yamlの方はTanzu PackagesのContourの設定ファイルと似ていることが分かる。
これより、kind: Appリソースで動いていると推測できる。ControlPlaneにログインして実際に見てみる。
（ログイン方法はこちらのkb参照。自己責任で利用すること）
$ kubectl get app -A --kubeconfig /etc/kubernetes/admin.conf
NAMESPACE NAME DESCRIPTION SINCE-DEPLOY AGE
vmware-system-pkgs tanzu-addons-manager Reconcile succeeded 10m 14d
vmware-system-pkgs tanzu-auth Reconcile succeeded 3m20s 14d
vmware-system-pkgs tanzu-capabilities Reconcile succeeded 2m26s 14d
vmware-system-pkgs tanzu-cliplugins Reconcile succeeded 3m43s 14d
vmware-system-pkgs tanzu-featuregates Reconcile succeeded 39s 14d
vmware-system-pkgs tanzu-framework Reconcile succeeded 2m19s 14d
vmware-system-pkgs tkr-service Reconcile succeeded 5m54s 14d
vmware-system-supervisor-services svc-contour.tanzu.vmware.com Reconcile succeeded 8m58s 131m
vmware-system-supervisor-services svc-harbor.tanzu.vmware.com Reconcile succeeded 7m10s 100m
HarborとContourのAppリソースが確認できた。トラブルがあった際はTanzu Packageと同じアプローチで臨むと良さそうだ。
おまけ２
公式ドキュメントの誤植が面白かった。
都道府県て。。。