Cloud Penguins

Flying penguins in the cloud.

HashiCorpに入社しました

本日Senior Solutions Engineerとして、HashiCorpに入社しました。

f:id:jaco-m:20210812121022j:plain

元々前職、前々職からHashiCorpのOSSプロダクトを利用していたことや、The Tao of HashiCorpという明確なプロダクトのビジョンを持っている点に魅力を感じて決めました。

HashiCorpもソフトウェアベンダーではあるのですが、競合するというよりは、どのベンダーのプロダクトとも上手く組み合わせてワークフローを作っていけるというプロダクト作りをしている点(Simple, Modular, Composable) も、CloudNative Daysをはじめとしたコミュニティ活動を行っている身としてはとても合っているなと感じています。

手始めに自宅のvSphere環境をTerraform管理に移行していくところから始めています。VaultもConsul使う形に作り替えていこうかな。

まずはHashiCorpプロダクトについて深く学んでいくオンボーディングの期間に入りますが、これまで以上に発信していければなと思っていますので、今後ともみなさまよろしくお願いします!

Tanzu Kubernetes Grid 1.4を新規構築した

先日Tanzu Kubernetes Grid 1.4が登場

tanzu.vmware.com

TKG1.3.1からのアップグレード方法はmaking先生が書いているのでそちらを見てもらうとして、自分は環境作り直しをしたかったので新規構築してみた。

CLIのセットアップ

まずは tanzu CLI等必要なものをセットアップ。基本的には以下のドキュメントを参照。

Install the Tanzu CLI and Other Tools

Customer connectからVMware Tanzu CLI 1.4.0 CLIをダウンロード(環境に応じてダウンロードするものは変わる)

https://customerconnect.vmware.com/en/downloads/info/slug/infrastructure_operations_management/vmware_tanzu_kubernetes_grid/1_x

そして tanzu のインストールとtanzu pluginのセットアップ、ytt などのCarvel toolを入れる流れ。

OVAテンプレートのダウンロードとアップロード

次にCustomer connectからOVAテンプレートを持ってくる。UbuntuもしくはPhoton、あるいはその両方をダウンロードしておく。

f:id:jaco-m:20210912175126p:plain

ダウンロードし終わったら、 vCenterからOVFテンプレートのデプロイ でデプロイ。その後テンプレートに変換 を行う。

f:id:jaco-m:20210912175426p:plain

このダウンロード&アップロード&変換は govc コマンドを使ってCLIで行うことも可能。そのあたりはmaking先生の記事を参照

Management Clusterのデプロイ

まずはManagement Clusterをデプロイする。CLIを使う方法とUIを使う方法の2つあるが、今回は初回インストールということもありUIを利用する。以下のコマンドを実行すると、 localhost:8080でUIが立ち上がるのでブラウザでアクセスする。もしも踏み台サーバ等で実行している場合は、sshのポートフォワード 例: ssh <踏み台サーバーIP> -L 8008:localhost:8080 を活用するなどしてブラウザから繋ぐと良い。

tanzu management-cluster create --ui -v 9

このような画面になるので、今回はvSphereを選択。ちなみにAWSとAzureを選ぶこともできる。

f:id:jaco-m:20210912175957p:plain

設定画面に入るので、必要項目を入れていく。まずはvCenterの設定。SSH PUBLIC KEYには、今後メンテナンス等でVMに繋ぐためのSSH公開鍵を入れる。

f:id:jaco-m:20210912180232p:plain

次にManagement Clusterの設定。インスタンスタイプはmedium以上が推奨。

f:id:jaco-m:20210912180316p:plain

どうやらTKG1.4から、Control planeのLBにNSX ALBが利用可能になった様子? (これまではkube-vipのみだった)

f:id:jaco-m:20210912180419p:plain

  1. VMware NSX Advanced Load Balancer のところは、NSX ALB利用者向けの設定なので今回は空欄

  2. MetadataもOptionalなので空欄で行ける。

RsourcesのところではvCenter上のリソースを指定。VMフォルダ、リソースプールは予めTKG向けに作っておくのがおすすめ。

f:id:jaco-m:20210912180908p:plain

次にネットワークの設定。作られたManagement ClusterのVMがぶら下がるvCenter上のネットワークを指定する。Cluster service CIDRやCluster pod CIDRは特に理由がなければそのままで良い

f:id:jaco-m:20210912181014p:plain

7 Identity Managementは、認証を外部のプロバイダーにしたい場合に設定する。この過去記事等を参照。

Auth0でTKGのクラスタを認証できるようにする - Cloud Penguins

OS Imageは先ほどアップロードしたOVAを指定。ubuntuもしくはphotonが選択出来る。

f:id:jaco-m:20210912181206p:plain

Register TMCはTanzu Mission Controlが利用可能な方は設定。

一通り設定が終わったら次に進める。すると設定の確認画面が出るので、下の方にある CLI Command Equivalent の内容をメモっておく。これは後々、CLIでのインストールを行う際に有用になる。

DEPLOY MANAGEMENT CLUSTERをクリックしてセットアップを開始。デプロイが終わったら以下のようにVMが作られていることが分かる。

f:id:jaco-m:20210912181505p:plain

Tanzu Kubernetes Cluster(Workload cluster)のセットアップ

次に、実際のワークロードを載せていくKubernetesクラスタを作る。参考にするドキュメントは以下。

docs.vmware.com

クラスタを作成するには、コンフィグファイルを作成してtanzuコマンドでデプロイする形になる。コンフィグテンプレートはドキュメントに記載されているのでコピーし、ファイルとして作成しておく。 今回自分は以下のような設定にした。環境に応じて適宜変更すること。

# CLUSTER_NAME:
CLUSTER_PLAN: dev
NAMESPACE: default
CNI: antrea
IDENTITY_MANAGEMENT_TYPE: none

#! Node configuration
#! ---------------------------------------------------------------------

VSPHERE_NUM_CPUS: 2
VSPHERE_DISK_GIB: 40
VSPHERE_MEM_MIB: 8000
CONTROL_PLANE_MACHINE_COUNT: 1
WORKER_MACHINE_COUNT: 2

#! ---------------------------------------------------------------------
#! vSphere configuration
#! ---------------------------------------------------------------------

VSPHERE_NETWORK: TKG
VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClNV5DBMYmOo5pYMpYE0PzXAFlLbYT46s6a7sGZdr9FIecJakrTtPVm6Po3uFL6qURi6uRQ8VsgeZGzZWWft8yJs1JdTcem8+KIiCenisTT7m9dRaX3EMdvhHyDtFGPSdGSq+blvgKo+HaHUem+Sx8R1lZAESzlZHjCwDxpZc5F/BkB4Jn+WiRgTeMwavOp0FJedNraLwZIHJ9h4kKV5uxIt3VgD5pHMotzjGJXDd2+jrcX6I/gQ/Cq1mXtvIMRoy72vpwF0r2knt1DrOOGi/Z029ZiPbQJl8HjbQSx/7kYPlw+ZI5W5afMSlwcs8qb3SR5ofF06gUftb3Uq/ziD2j                                                               VSPHERE_USERNAME: administrator@vsphere.local
VSPHERE_PASSWORD: <PASSWORD>
VSPHERE_SERVER: vcenter.udcp.run
VSPHERE_DATACENTER: Datacenter
VSPHERE_RESOURCE_POOL: tkg
VSPHERE_DATASTORE: vsanDatastore
VSPHERE_FOLDER: tkg
VSPHERE_INSECURE: true
VSPHERE_CONTROL_PLANE_ENDPOINT: 10.9.11.101

#! ---------------------------------------------------------------------
#! Machine Health Check configuration
#! ---------------------------------------------------------------------

ENABLE_MHC: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m

#! ---------------------------------------------------------------------
#! Common configuration
#! ---------------------------------------------------------------------

ENABLE_AUDIT_LOGGING: false
ENABLE_DEFAULT_STORAGE_CLASS: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13

# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""

#! ---------------------------------------------------------------------
#! Autoscaler configuration
#! ---------------------------------------------------------------------

ENABLE_AUTOSCALER: false

コンフィグファイルの編集が終わったら以下のコマンドでデプロイを開始

tanzu cluster create workload -f workload.yaml

Management clusterに加え、workload clusterも構築されたことが分かる。

f:id:jaco-m:20210912182219p:plain

動作確認

終わったら以下のコマンドでkubeconfigを取得し、k8sに接続を確認。

tanzu cluster kubeconfig get workload --admin
kubectl config use-context workload-admin@workload
 kubectl get pods -A
NAMESPACE                           NAME                                                             READY   STATUS      RESTARTS   AGE
avi-system                          ako-0                                                            1/1     Running     0          67m
capi-kubeadm-bootstrap-system       capi-kubeadm-bootstrap-controller-manager-6494884869-8r5v7       2/2     Running     0          72m
capi-kubeadm-control-plane-system   capi-kubeadm-control-plane-controller-manager-857d687b9d-fxx75   2/2     Running     0          72m
capi-system                         capi-controller-manager-778bd4dfb9-tskmh                         2/2     Running     0          72m
capi-webhook-system                 capi-controller-manager-9995bdc94-7sj5n                          2/2     Running     0          72m
capi-webhook-system                 capi-kubeadm-bootstrap-controller-manager-68845b65f8-d7zs5       2/2     Running     0          72m
capi-webhook-system                 capi-kubeadm-control-plane-controller-manager-9847c6747-8fzkp    2/2     Running     0          72m
capi-webhook-system                 capv-controller-manager-55bf67fbd5-5shl8                         2/2     Running     0          72m
以下略

無事にKubernetesとして機能していることが確認できた。

その他1.4に関すること

基本的にデプロイの流れはTKG 1.3と変わるところはない。

TKG1.3にはadd-onという概念があったが、1.4からはpackageという仕組みに変更が行われた。そのため1.3からのアップデートの場合はadd-onをpackageに更新する作業が必要となる。extensionsを利用している場合も同様。

アップデート方法は例によってこちらの記事と、あとは公式ドキュメントを参考にするとよい。

VMUG Advantageに登録した

退職にともない、これまで自宅で検証用に使っていたライセンスたちが使えなくなってしまう。

jaco.udcp.info

しかし次の仕事もVMware製品と完全に無縁というわけではなく、やっぱり検証用途に環境は残しておきたい。

ということで、VMUG (VMware Users Group) に参加して、有料のAdvantageに登録することにした。

www.vmug.com

Advantageに登録すると、トレーニングのディスカウントやVMworld参加へのディスカウントがついてくるほか、365日の検証用ライセンスが利用可能になる。

検証可能なライセンスはこんな感じ。

f:id:jaco-m:20210910235505p:plain

Advantageへの登録方法はこのあたりの記事を参考にした

zokibayashi.hatenablog.com

1年、2年、3年と選べるのだけど、思い切って3年のプランにしてみた。

f:id:jaco-m:20210910234757p:plain

(ノ´∀`)ノ

EKS AnywhereをProductionでデプロイした話

先に謝っておくと、タイトルは半分釣り。嘘はついていないのだけど。

ということでEKSをオンプレ環境で動かせるEKS Anywhere (以下EKS-A)がGAに。 aws.amazon.com

現時点で対応している構築環境は、ローカルのDocker上で動かすか、あるいはvSphere環境の2択。"ちゃんとした"環境で動かすとなると、vSphereが第一の選択肢と言うことになりそう。

EKS-Aのドキュメントを見ると、Create production clusterの項目でvSphereに構築する方法が解説されている。今回のタイトルはつまりそういうことで、EKS-AをvSphereにデプロイしてみましたよ、というお話。

EKS-Aの準備をする

EKS-Aでは、環境の構築にCluster APIが使われている。VMwareのTanzu Kubernetes GridもCluster APIなので、vSphere環境でk8sを構築するのであればCluster API、というのが一般的になりそう。

Cluster APIはこのマスコットキャラクターがめちゃくちゃ上手く仕組みを表現していて、Kubernetes Clusterの中にインストールされたCluster APIが、さらにクラウドプロバイダーにアクセスして別のKubernetesを立ち上げるという、親亀子亀のような仕組みになっている。

なので、まずは作業環境にDockerを立ち上げ、その中に eksctl anywhere コマンドでbootstrapのクラスタを立ち上げられるようにする。

EKS-Aのドキュメントでは、この作業環境のことを Administrative machine と呼んでおり、現時点ではMac OSか、Ubuntuを公式ではサポートしている。他のディストリビューションでもいけるのではと思うが、試していないので分からないし、無駄なトラブルを避けるためにもまずは推奨環境で行うのが良いだろう。今回はWindowsのWSL2でセットアップしてあるUbuntu 20.04 + Docker Desktopという構成でやってみた。WSL2+Docker Desktopの時点で公式サポートの環境じゃなくなっている気もするが、少なくとも自分の環境では動いた。

Dockerのインストール方法は割愛。

以下のコマンドで最新の eksctl をインストール。バージョン0.66.0が入るはずだ。

curl "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" \
    --silent --location \
    | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin/

次に eksctl-anywhere pluginをセットアップ。

export EKSA_RELEASE="0.5.0" OS="$(uname -s | tr A-Z a-z)"
curl "https://anywhere-assets.eks.amazonaws.com/releases/eks-a/1/artifacts/eks-a/v${EKSA_RELEASE}/${OS}/eksctl-anywhere-v${EKSA_RELEASE}-${OS}-amd64.tar.gz" \
    --silent --location \
    | tar xz ./eksctl-anywhere
sudo mv ./eksctl-anywhere /usr/local/bin/

AWSのトリさんが教えてくれたところによると、このプラグイン機構はeksctl 0.66.0から導入されたということなので、もし上手く動かない場合はeksctlのバージョンを確認してみると良い。

vSphere側の準備をする

次にvSphere側の準備をする。 Productionというだけあって、リソースはガッツリ必要になる。 デフォルトだと7VM立ち上がるのだが、それぞれに2 vCPU, 8GB RAM, 20GB Diskが必要だ。つまり14 vCPU, 56GB RAM。 オーバーコミットをしたとしても、まぁそれなりに覚悟は必要なリソース量にはなるだろう。 自分はたまたまガッツリ試せる環境を自宅に組んでいたので問題なかったのだが。

また、vSphereのバージョンはvSphere7.0以上が必須。自分は最新の7.0U1cを利用した。

利用するネットワークにはDHCPが必須。この制約はTKGと一緒なのだが、割と引っかかりやすいポイントなので要注意。

まず、vCenterからResource poolを作成。今回はEKSAという名前にしてみた。 f:id:jaco-m:20210910022451p:plain

次にフォルダを作成。新規仮想マシンおよびテンプレートフォルダを選択し、 EKSAという名前で作成。 f:id:jaco-m:20210910022925p:plain

また、これはドキュメントに無くてハマりポイントだが、Templates という名前のフォルダも併せて作っておく。これを作らないとエラーでコケてしまった。

Cluster configを作る

以下のコマンドでコンフィグファイルを生成

CLUSTER_NAME=prod
eksctl anywhere generate clusterconfig $CLUSTER_NAME \
   --provider vsphere > eksa-cluster.yaml

生成したコンフィグファイルを開いてみると、KubernetesのYAMLになっており、Cluster APIによるリソースが定義されていることが分かる。

次にこのファイルの必要事項を修正する。

まずClusterリソースのendpointを修正。これが作成されるKubrenetesのAPIエンドポイントになる。

  controlPlaneConfiguration:
    count: 2
    endpoint:
      host: "10.9.8.190" #これ
    machineGroupRef:

同じリソースで externalEtcdConfiguration workerNodeGroupConfigurations controlPlaneConfiguration が設定可能になっていて、count の値を変更することでVMの台数を変えることが出来る。必要に応じて変更しよう。

次に、VSphereDatacenterConfigを修正。

apiVersion: anywhere.eks.amazonaws.com/v1alpha1
kind: VSphereDatacenterConfig
metadata:
  name: prod
spec:
  datacenter: "Datacenter" #必須
  insecure: true #任意
  network: "VM Network" #必須
  server: "vcenter.udcp.run" #必須
  thumbprint: "" #任意

datacenter にはvSphere上のDatacenter、 networkにはVMをぶら下げたいネットワーク、 serverにはvCenterのアドレスを入れておく。vCenterが自己署名証明書の場合は insecureを true にするか、 thumbprintを設定する。

次に、 3つあるVSphereMachineConfigを修正。 prod-cpがk8sのcontrol plane、prod-etcdがetcd、prodがworker nodeのリソースになっている。それぞれ別の値を設定可能だが、今回は全て同じ設定を施すことにする。

以下のコメントが付いている部分を、環境に合わせて変更する

spec:
  datastore: "vsanDatastore" # 利用したいデータストア
  diskGiB: 25
  folder: "EKSA" # さっき作成した仮想マシンのフォルダ
  memoryMiB: 8192
  numCPUs: 2
  osFamily: bottlerocket # 利用したいOSを指定。今回はbottlerocket 
  resourcePool: "EKSA" #さっき作成したリソースプール
  users:
  - name: ec2-user #bottlerocket の場合はec2-userを指定
    sshAuthorizedKeys:
    - "ssh-rsa AAAAB3NzaC1yc...j" #作成されたVMにログインできるようにするための公開鍵を入れておく

デプロイする!

vCenterにアクセスするための認証情報を環境変数に入れておく。

export EKSA_VSPHERE_USERNAME='administrator@vsphere.local'
export EKSA_VSPHERE_PASSWORD='t0p$ecret'

そして以下のコマンドで構築開始。

eksctl anywhere create cluster -f eksa-cluster.yaml -v 9

ドキュメントには無かったが、 -v オプションでログレベルを変更できるとトリさんが教えてくれた。ありがたや。初期構築の場合何かとコンフィグの設定ミスを起こしやすいのだが、デフォルトのログレベルだと進捗がほとんど表示されないのでエラーが起きていても気づきにくい。 -vで高めの数字をしておくことで、トラブル時にも状況を把握しやすくなる。

最終的に以下のような表示がされれば構築完了。

f:id:jaco-m:20210910024815p:plain

作られたものを見ていく。

リソースグループを見てみると、7台のVMが構築されていることが分かる。ちなみに画像の下のリソースグループはVMware Tanzu Kubernetes Gridで構築した環境だ。同じCluster APIを利用しているため、VMの命名ルールが似ていることが分かるだろう。

f:id:jaco-m:20210910025242p:plain

コンテンツライブラリを見てみると、eks-a-templates という名前のライブラリが作成されており、その中にOVAテンプレートが追加されている。現バージョンではbottlerocketとubuntuが選択可能なのだが、ubuntuイメージは8.64GBと巨大のため、VMの起動が非常に遅かった・・・。Tanzu Kubernetes Gridの場合はubuntuでも1.5GB程度なので、何故こんなにサイズが大きいのかは謎。

f:id:jaco-m:20210910025336p:plain

作成されたk8sにアクセスするには、kubeconfigファイルが生成されているのでそれを指定

export KUBECONFIG=${PWD}/${CLUSTER_NAME}/${CLUSTER_NAME}-eks-a-cluster.kubeconfig

叩いてみると色々動いていることがわかる。 f:id:jaco-m:20210910030158p:plain

kubeconfigを毎回指定するのが面倒なので、必要であれば ~/.kube/config に内容をマージしたほうがいいかもしれない。

CNIにはCiliumが利用されている。CSIは標準でvSphere CSIが設定されているため、そのままPVが作成可能だ。

kubectl get sc
NAME                 PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
standard (default)   csi.vsphere.vmware.com   Delete          Immediate           false                  76m

LoadBalancerは、ドキュメントだとKube-vipの利用がRecommendedになっている。(個人的にあまりいい印象がないのだけど・・・)

ちなみに既にControl planeにはkube-vipがデプロイされており、Kubernetes APIの公開に利用されている。

その他FluxによるGitOpsがサポートされているなどいくつか特徴があるので、皆さんお試しあれ(これはDockerで構築しても使えるはず)

ハマったこと

オンプレならではというか、環境の差異によるハマりポイントがあったので以下メモ

public.ecr.awsからaccess denied食らって死んだ

パブリックの方のECRを以前使っていたんだけど、そのログイン情報が切れていたのかいきなりこれを食らった。get-login-passwordをやり直して解消。

eksctl anywhere create cluster -f eksa-cluster.yaml
Error: failed to create cluster: unable to initialize executables: failed to setup eks-a dependencies: Error response from daemon: pull access denied for public.ecr.aws/eks-anywhere/cli-tools, repository does not exist or may require 'docker login': denied: Your authorization token has expired. Reauthenticate and try again.

コンテンツライブラリで死んだ

若干分かりづらいエラーだったが、コンテンツライブラリへの転送でエラーと出た。原因としては、vCenterのDNS設定が間違っており名前が引けない状態だったため、OVAファイルをインターネットから持ってこれずこのエラーになった様子。この状態になってしまうと、DNS設定を直してもコンテンツライブラリにゴミが残っており、そのゴミを手動で消してあげる必要があった。

Creating template. This might take a while.
❌ Validation failed    {"validation": "vsphere Provider setup is valid", "error": "failed importing template into library: error importing template: govc: The import of library item d7869312-b889-4400-b489-af20cf1e177f has failed. Reason: Error transferring file bottlerocket-v1.21.2-eks-d-1-21-4-eks-a-1-amd64.ova to ds:///vmfs/volumes/vsan:5208a8224f1b7452-258c9915a44aa6a5//contentlib-b06b09de-5b24-4be6-86a9-b344590a9681/d7869312-b889-4400-b489-af20cf1e177f/bottlerocket-v1.21.2-eks-d-1-21-4-eks-a-1-amd64_c4187670-2a9b-4a5b-86dd-a1e8a0bd0d18.ova?serverId=86f3a054-9ba4-4b8f-81b6-b7070451c5cc. Reason: Error during transfer of ds:///vmfs/volumes/vsan:5208a8224f1b7452-258c9915a44aa6a5//contentlib-b06b09de-5b24-4be6-86a9-b344590a9681/d7869312-b889-4400-b489-af20cf1e177f/bottlerocket-v1.21.2-eks-d-1-21-4-eks-a-1-amd64_c4187670-2a9b-4a5b-86dd-a1e8a0bd0d18.ova?serverId=86f3a054-9ba4-4b8f-81b6-b7070451c5cc: IO error during transfer of ds:/vmfs/volumes/vsan:5208a8224f1b7452-258c9915a44aa6a5/contentlib-b06b09de-5b24-4be6-86a9-b344590a9681/d7869312-b889-4400-b489-af20cf1e177f/bottlerocket-vmware-k8s-1.21-x86_64-1.2.0-ccf1b754_c4187670-2a9b-4a5b-86dd-a1e8a0bd0d18.vmdk: Pipe closed.\n", "remediation": ""}
Error: failed to create cluster: validations failed

Templateの作成で死んだ

これは本文中にも書いた通り。ドキュメントの記載漏れなんじゃないかなー? Template用のフォルダを作っておく必要がある。

❌ Validation failed    {"validation": "vsphere Provider setup is valid", "error": "failed deploying template: error deploying template: govc: folder '/Datacenter/vm/Templates' not found\n", "remediation": ""}
Error: failed to create cluster: validations failed

タグが適切に設定されなくて死んだ

これ、諸々試行錯誤してたら突然出なくなって解消して、結局原因は謎。 テンプレートに必要なタグが設定されておらず死ぬパターン。 この問題を引いてしまった場合は、手動でTemplateファイルのタグにosFamilyの設定を入れてあげる必要があった。

f:id:jaco-m:20210910032218p:plain

❌ Validation failed    {"validation": "vsphere Provider setup is valid", "error": "failed tagging template: govc returned error when attaching tag to /Datacenter/vm/Templates/bottlerocket-v1.21.2-kubernetes-1-21-eks-4-amd64-a440064: govc: 400 Bad Request: {\"type\":\"com.vmware.vapi.std.errors.invalid_argument\",\"value\":{\"error_type\":\"INVALID_ARGUMENT\",\"messages\":[{\"args\":[\"urn:vmomi:InventoryServiceTag:28bd7acf-262b-4c48-a53a-775ed91b34e1:GLOBAL\",\"DynamicID (com.vmware.vapi.std.dynamic_ID) => {\\n    type = VirtualMachine,\\n    id = vm-1554590:86f3a054-9ba4-4b8f-81b6-b7070451c5cc\\n}\"],\"default_message\":\"Tagging associable types violation\",\"id\":\"\"}]}}\n", "remediation": ""}
Error: failed to create cluster: validations failed

etcd以外のノードが上がらずに死んだ

これ、結局原因が分からず、何もしてないのに直った・・・(マジ)

bottlerocketでこの問題を引き、その後ubuntuにしたら普通に立ち上がった。 で、その後bottlerocketに戻したら何故かちゃんと立ち上がった・・・。

VMwareを退職します

このたびVMwareを退職することになりました。数週間前から有休消化期間に入っており、今週末をもって退職となります

有休消化期間は、Cloud Operator Days Tokyo 2021のシステム周りをお手伝いしていたり、CI/CD Conference 2021を開催したりしてました。

VMwareに入社したのは2020年の春。それから考えると僅か1年半なのですが、元々はPivotalという会社に所属しており、買収を経てVMwareとなったので、Pivotal時代から通算するとおおよそ4年半在籍していたことになります。

そもそも何をしてたんだっけ

PivotalおよびVMwareでは、Senior Solutions Architectというポジションに居ました。一般的にSolutions Architectというとプリセールスエンジニアを指すことが多いのですが、Pivotalの場合は製品を購入していただいたお客様に対して導入の支援やコンサルティングを行う、いわゆるプロフェッショナルサービスと呼ばれる類いの仕事をしていました。

元々NTT CommunicationsでCloud FoundryをベースとしたPaaSを開発していたこともあり、Cloud Foundryの本家本元であるPivotalに転職したという経緯があります。Pivotalでは商用版であるPivotal Cloud Foundryや、KubernetesディストリビューションのPivotal Container Service、VMwareになってからはVMware Tanzu(Pivotalから継承した製品含む) 周りのプロダクトの導入支援に携わっていました。

自分がCloud Foundryに触れたのは2011年のことだったので、NTT Com->Pivotal->VMwareと延べ10年に渡り、このPaaSに関わってきたことになりますね。時が経つのは早いなぁ。

Pivotalってすごかったんだよ

Pivotalは2013年に設立された非常に若い会社でしたが、 Transform How The World Builds Software - 世界のソフトウェアの作り方を変える- のミッションのもと、主に大企業に向けたプロダクトとサービスの提供を行っていました。単にプロダクトを提供するのではなく、ソフトウェアの変革に必要なのはチームとその文化であるという強い信念を全社員が持って取り組んでおり、その信念に反する(Pivotalっぽくない) ことはやらないという、言うなれば我の強い会社だったなあと思います。

f:id:jaco-m:20200929200747j:plain ▲ Pivotalのコアバリュー。今見ても良いなって思う

ビジネスの対象としては、いわゆるエンタープライズと呼ばれる超大企業がメインでしたが、そういったビジネスの会社にありがちな堅さは全くなく、めちゃくやオープンでフレンドリーなカルチャーでした。春になるとオフィスに桜が咲き、秋にはカボチャが生え、それが終わるとクリスマスツリーが生える。いつも卓球台からは楽しそうな声が聞こえる。そんな環境でした。

f:id:jaco-m:20180404111136j:plainf:id:jaco-m:20190315170947j:plainf:id:jaco-m:20181025112616j:plainf:id:jaco-m:20171114203434j:plainf:id:jaco-m:20171031173808j:plain

こういうのをみると、「あ、シリコンバレーの会社っぽいな」って思うかもしれませんが、まさにそれ。Pivotalの場合は、Pivotalという存在自体がある意味商材そのもので、自らが持つソフトウェア開発に向いたシリコンバレーの文化を、エンタープライズにも広げていくという考えでやっていました。 "Silicon valley is not just a place, it's a state of mind" (シリコンバレーとは地名ではなく、マインドセットである) ともよく言っていましたね。

Platform as a Product

前述したように、自分はソフトウェア開発ではなく、Pivotal Cloud Foundryを中心としたクラウドのプロダクトを中心に担当していましたが、それでもこのPivotal文化による影響はバンバン受けていました。

その中でも、Platform as a Product(プロダクトとしてのプラットフォーム) という考え方に触れられたことは、自分が十数年この業界で生きてきた中でも最も衝撃的でした。一言でいうと、「役に立つプラットフォームを作るのであれば、それをプロダクトとして育てよう」という考え方なのですが、この一文で衝撃度合いを伝えるのが難しいので、CloudNative Days Tokyo 2020で発表した以下のセッションを見て欲しい。

スライド speakerdeck.com

動画 event.cloudnativedays.jp

記事 thinkit.co.jp

また改めて整理してブログに書いてもいいなと考えてたりします。

じゃあなんで辞めるの

Pivotalのすごさを語るといくらでも書けてしまうので一旦この辺にしておきますが、じゃあ何故今回退職することになったか。

まあ、VMwareはPivotalじゃなかったから という点は間違いなく理由としてあるのですが、これだけだとネガティブに伝わってしまうのでもう少し補足。

VMwareになってからは1年半経つのですが、実は大きな不満というものはないんですよね。良くも悪くも小さい会社(といっても数千人いたけど)だったPivotalに比べると、こちらは数万人規模の巨大なソフトウェアベンダー。体制の充実度は圧倒的に高く、待遇としてもPivotal時代よりも圧倒的に良くなりました。仕事の内容も同僚もポジションも変わらないのに待遇がめっちゃ良くなるの、不思議な体験でした。

また、PaaSやCaaSといったチャレンジングなプロダクトを中心としたPivotal時代と比べれば、VMwareには圧倒的なパワーを誇るプロダクトがずらっと並んでいる。こういった足腰のしっかりしたプロダクトの上に、VMware Tanzuという新しいプロダクトを載せるという形になったので、安定度(プロダクト、マーケティング双方)を増しつつも新しいことをやれるといういいとこ取りな状況になったのです。強い。

ただ、プロダクト力で推していくビジネスは強力な一方、社員に求められるものも必然と変わってくることになりました。買収と会社の成長を通じて、良い意味で フェーズが変わった んだなと個人的には考えていて、じゃあどうするかと考えた末、自分としても新しいことやろうと思い、今回の決断に至った次第です。

次は何するの

来週から新しい職場になるので、それは改めて書こうかなと思っています。 が、業界としてはほぼ同一(直接のコンペではない) なところに居るので、今居るコミュニティには引き続き参加していくつもりですし、VMwareプロダクトにも継続して触れていきたいなと思っています。

あ、VMwareの社員向けのライセンス使えなくなるから、VMUG Advantage入らないとな。

あと、11月4-5に開催するCloudNative Days Tokyo 2021、現在CFPオープンしていて締め切りは明日 9/8です!クラウドネイティブ技術に関するものであれば何でも審査の対象となりますので、ネタのある方は急いでご応募ください!

event.cloudnativedays.jp

あと定番のほしいものリスト

Amazon.co.jp

Synology上のDockerでPort80,443が使えない件をなんとかする

TL;DR

SynologyでPort 80や443を使うコンテナ動かしたければ、 システムのnginxをリバースプロキシとして使おう。

/etc/nginx/sites-enabled に nginxのVirtual Hostの設定をぶっ込んでリロードすれば行ける

自宅サーバーとしてSynology便利だけど・・・

みんな大好きSynologyのNAS。

一般家庭でも手の届きやすい金額で入手できる上に、豊富なパッケージにより単なるネットワークストレージだけでなく、サーバーとしての機能も持たせられる。メディアサーバーにもできるしウェブサーバーにも出来る。何ならLDAPサーバーやActiveDirectoryも出来ちゃう。パッケージにないものであれば、ハイパーバイザも提供しているのでVMで建てることもできるし、Dockerパッケージもあるのでコンテナとして立ち上げてしまえば実質何もできちゃう。マジ便利。

自宅で勉強がてらKubernetesクラスタを立ち上げているような人であれば、有志によりSynology CSIが提供されているのでPVをここに持ってくることも出来てしまう。便利。

github.com

Dockerでウェブサーバーが立ち上げられないぞ・・・!

じゃあDockerで何でも立ち上げられるんだね、やったー! ということで、Synology上のDockerでnginxを立ち上げようとすると、こういうエラーになってしまい立ち上げられない。

jacopen@synology:~$ sudo docker run -p 80:80 nginx

docker: Error response from daemon: driver failed programming external connectivity on endpoint epic_turing (3f98a359a914e07caa28b26ec4900650668df4eeecdefd28fca18be4a799e974): Error starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use.
ERRO[0001] error waiting for container: context canceled

tcp 0.0.0.0:80: bind: address already in use. はい。80番や443番は既にシステムによって使われてしまっているため、Dockerから叩けないのである。実際SynologyのIPをブラウザで叩くと、5000番にリダイレクトされてDSM(DiskStation Manager)の画面が表示されることが分かるだろう。

単に静的なコンテンツをホストするだけであれば、パッケージでいくつかのウェブサーバーが提供されているのでそれを使えば良い。 f:id:jaco-m:20210818201241p:plain

しかし、Dockerで立ち上げてたウェブアプリに対してSynologyのIP経由で80や443経由でアクセスさせたいというケースも多いだろう。実際自分も、S3互換のオブジェクトストレージであるMinioや、コンテナレジストリであるHarborをSynology上に立ち上げようとしてこの問題に当たってしまった。

Synology上の80や443は誰が使っているのか

じゃあこのSynology上の80や443は誰が使っているのか。SynologyにSSHでログインしてnetstatしてみるとこう出る。

$ sudo netstat -anp | grep -e "0.0.0.0:80" -e "0.0.0.0:443"
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      13584/nginx: master
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      13584/nginx: master

どうやらnginxが立ち上がっているようだ。これはWebサーバーのパッケージを入れなくても、必ず立ち上がっている。

またDSMのデフォルトポートである5000や5001も、nginxを経由していることが分かる

$ sudo netstat -anp | grep -e "0.0.0.0:5000"
tcp        0      0 0.0.0.0:5000            0.0.0.0:*               LISTEN      13584/nginx: master

nginxに任意の設定を食わせる

これらの設定ファイルは、/etc/nginx に存在する。 /etc/nginx/nginx.conf を親として、 /etc/nginx/app.d/etc/nginx/conf.d に個別の設定が格納されている。DSM自体や、パッケージでインストールした各アプリケーションへのルーティングも、app.dやconf.dに格納されるようになっている。

/etc/nginx/nginx.conf を開いてみると、以下のような記述があることが分かる。

    include conf.d/http.*.conf;
    include app.d/server.*.conf;
    include sites-enabled/*;

そう、 nginxがこれらのファイルをincludeしてくれるのである。なので、nginxをリバースプロキシとすれば任意のアプリに対してルーティングを設定出来るというわけだ。

ただ、app.d配下に関してはDSMをアップグレードすると初期化されて消えてしまう。そこで、sites-enabled内に以下のようなファイルを設置した。

server {
  server_name minio.udcp.run;
  listen 80;
  access_log /var/log/nginx/concourse.access.log;
  location / {
          proxy_set_header Host $http_host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto $scheme;
          client_max_body_size 100M;
          proxy_pass http://localhost:9000/;
  }
}

DockerでPort 9000でMinioを立ち上げている。minio.udcp.runへのリクエストがあった場合は、そこへのリバースプロキシとして機能するという設定だ。

コンフィグファイルの作成が終わったら、以下のコマンドでnginxをリロードする。

sudo synoservice --reload nginx

無事ブラウザからアクセス出来た。

f:id:jaco-m:20210818210019p:plain

なお、この設定はDSM 6.2系で確認している。最新の7系ではどうなるかはまだ未確認。

Auth0でTKGのクラスタを認証できるようにする

TKGでは、認証に外部Identity Provider(IdP)を利用することができる。TKG1.3以降はPinnipedというコンポーネントが含まれており、これが外部IdPを担った認証を行うようになっている。

Pinnipedについては星野さんのCNDO2021の発表が参考になるので興味のある方は是非。

event.cloudnativedays.jp

OpenID Connectを使った認証はTKGのドキュメントに記載があるのだけど、これはOktaを使った説明になっている。 自分は普段Auth0をIdPとして使っており(CNDT/CNDOもAuth0)、そちらを使ったログインをやりたいなと思い、今回の記事を書くことにした。

なおOkta/Auth0に限らずOpenID ConnectなIdPであれば似たような設定で利用可能だと思うので、適宜読み替えて活用してもらえれば。

Management Clusterの構築手順

これ以降の解説はTKG1.3.1 を前提とする。

Management Clusterを作る

Management Clusterの作り方は、1点を除き通常とほぼ変わりなし。今回はUIを使って構築してみる。

$ tanzu management-cluster create --ui

f:id:jaco-m:20210530141517p:plain いつもの画面。今回はvSphereを使うが、認証周りについてはEC2でもAzureでも同じだと思われる。

f:id:jaco-m:20210530141623p:plain Iaas Providerの設定は通常と変わらず。各自利用している環境に合わせて変更。

f:id:jaco-m:20210530141705p:plain Management Cluster Settings。ここも通常と変わらないが、 CONTROL PLANE ENDPOINT の値だけちゃんとメモしておくこと。後で使います。

この後 6. Kubernetes Networkまでは通常と一緒なので割愛。

次に7. Identity Management。ここが一番のポイント。一旦TKG側の設定はここで止めておいて、Auth0の設定に入る。

Auth0の設定をする

auth0.com Auth0にログインをする。アカウントを持っていない方は新規登録しておきましょう。今回の用途くらいであれば無料の範囲内で利用可能。

f:id:jaco-m:20210530142544p:plain ログインしたら、Applications-> Create Applicationをクリック。

f:id:jaco-m:20210530142651p:plain Nameは任意の名前を。application typeはRegular Web Applicationsを選ぶ。

f:id:jaco-m:20210530143203p:plain 次にアプリケーションの設定にはいるが、すこし下にスクロールしたところにあるApplication URIsのAllowed Callback URIsに https://<Control PlaneのIP>:31234/callback を入れる。IPには先ほど控えたControl Planeの値を。これが出来たら一旦Save。

TKGのOIDCの設定をする

Auth0の画面を開いたままTKGの画面に戻る。 f:id:jaco-m:20210530143847p:plain Identity Managementの項目に、Auth0の値を転記していく。

  • ISSUER URL - http://<Auth0 appのDomain>/
    • https:// および 末尾のスラッシュを忘れないこと。これを忘れるとログインが失敗する
  • CLIENT ID - Auth0のClient ID
  • CLIENT SECRET - Auth0のClient Secret
  • SCOPES - openid,groups,email
  • USERNAME CLAIM - どの値をUsernameとして扱うか。今回は email を指定
  • GROUPS CLAIM - どの値をGroupとして扱うか。今回は groups を指定

入れ終わったらNEXTをクリック。残りの設定は通常のクラスタ作成と変わらない。

f:id:jaco-m:20210530144528p:plain 全ての設定が終わったらインストールを開始。しばらく待ち。

Management Clusterの設定

Management Clusterの設定が終わったら、次は tanzu コマンドを使ってadminのkubeconfigを取得。この段階ではOIDC認証は使っていない。

$ tanzu management-cluster kubeconfig get --admin
Credentials of cluster 'demo' have been saved
You can now access the cluster by running 'kubectl config use-context demo-admin@demo'
$ kubectl config use-context demo-admin@demo
Switched to context "demo-admin@demo".

Pinniped周りのPodが正しく上がっているかを確認。この段階で何らしかのErrorが発生していたら、コンフィグを間違っている可能性があるので kubectl logs などを使って確認する。

$ kubectl get all -n pinniped-supervisor
NAME                                      READY   STATUS      RESTARTS   AGE
pod/pinniped-post-deploy-job-bfzhn        0/1     Completed   0          3m4s
pod/pinniped-supervisor-f5dd7d547-pbxbd   1/1     Running     0          2m20s
pod/pinniped-supervisor-f5dd7d547-xjw8l   1/1     Running     0          2m20s

NAME                          TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
service/pinniped-supervisor   NodePort   100.65.72.169   <none>        443:31234/TCP   3m4s

NAME                                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/pinniped-supervisor   2/2     2            2           3m4s

NAME                                            DESIRED   CURRENT   READY   AGE
replicaset.apps/pinniped-supervisor-f5dd7d547   2         2         2       3m4s

NAME                                 COMPLETIONS   DURATION   AGE
job.batch/pinniped-post-deploy-job   1/1           44s        3m4s

次に、OIDC経由のユーザーにClusterRoleを付与する。今回はManagement Clusterの全権を付与したいので、cluster-admin をユーザーにつける。ユーザーに与える権限を絞りたい場合は、ここで別のClusterRoleやRoleをbindingすれば良い

$ kubectl create clusterrolebinding cluster-admin-jacopen --clusterrole cluster-admin --user jacopen@gmail.com
clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-jacopen created

終わったら、OIDCで認証するためのkubeconfigを出力する。今回は /tmp/mgmt_oidc_kubeconfig に出力している

$ tanzu management-cluster kubeconfig get --export-file /tmp/mgmt_oidc_kubeconfig
You can now access the cluster by running 'kubectl config use-context tanzu-cli-demo@demo' under path '/tmp/mgmt_oidc_kubeconfig'

出力したkubeconfigを使ってリソースを取得してみる。

kubectl --kubeconfig /tmp/mgmt_oidc_kubeconfig get all

すると、自動的にブラウザが立ち上がってAuth0の認証画面に飛ばされるので、Auth0に設定してある認証手段(user/pass, Google, GitHubなど)を利用してログイン。すると、ブラウザには以下のように表示され、kubectl側では無事にレスポンスが帰ってきているはず。

f:id:jaco-m:20210530155644p:plain

これで無事Management ClusterをOIDCのユーザー経由で利用できるようになった。

OIDC経由のユーザーでtanzuコマンドを利用できるようにする

OIDC経由のユーザーをcluster-adminにしたので、そのユーザーを使ってtanzuコマンドからclusterの作成等が可能になる。

環境を分けるために別ユーザーを作成の後、 tanzu login --endpoint "https://<Management Cluster IP>:6443" --name <Management Cluster名> を実行。

すると自動的にブラウザが立ち上がり、Auth0での認証が行われる。認証が通れば以下ののようになる。

$ tanzu login --endpoint "https://10.9.11.103:6443" --name demo
✔  successfully logged in to management cluster using the kubeconfig demo
$ tanzu management-cluster get
  NAME  NAMESPACE   STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES
  demo  tkg-system  running  1/1           1/1      v1.20.5+vmware.1  management


Details:

NAME                                                     READY  SEVERITY  REASON  SINCE  MESSAGE
/demo                                                    True                     113m
├─ClusterInfrastructure - VSphereCluster/demo            True                     113m
├─ControlPlane - KubeadmControlPlane/demo-control-plane  True                     113m
│ └─Machine/demo-control-plane-kp9pv                     True                     113m
└─Workers
  └─MachineDeployment/demo-md-0
    └─Machine/demo-md-0-86cb4697d7-sm8p8                 True                     113m


Providers:

  NAMESPACE                          NAME                    TYPE                    PROVIDERNAME  VERSION  WATCHNAMESPACE
  capi-kubeadm-bootstrap-system      bootstrap-kubeadm       BootstrapProvider       kubeadm       v0.3.14
  capi-kubeadm-control-plane-system  control-plane-kubeadm   ControlPlaneProvider    kubeadm       v0.3.14
  capi-system                        cluster-api             CoreProvider            cluster-api   v0.3.14
  capv-system                        infrastructure-vsphere  InfrastructureProvider  vsphere       v0.7.7

tanzuコマンドを使ってManagement clusterの情報を得ることができた。