OPENSHIFT4.2のインスト レーションツールに見るクラ スタの構築方法について @genboku

2 本日の流れ 1. Kubernetesのアーキテクチャ 2. Self Hosting Kubernetes 3. OpenShiftのインストール

3 Kubernetesのアーキテクチャ Kubectl API server replication, namespace, serviceaccounts, etc. -controller- manager -scheduler etcd Master node Worker node kubelet kube-proxy Container Runtime Pod Pod Containers Containers Worker node kubelet kube-proxy Container Runtime Pod Pod Containers Containers Internet https://github.com/Azure/aks-bestpractices- ignite19/blob/master/slides/ignite19_bestpractices_v2.pptx より改変

4 Kubernetesのアーキテクチャ Kubectl API server replication, namespace, serviceaccounts, etc. -controller- manager -scheduler etcd Master node Worker node kubelet kube-proxy Container Runtime Pod Pod Containers Containers Worker node kubelet kube-proxy Container Runtime Pod Pod Containers Containers Internet https://kubernetes.io/ja/docs/concepts/overview/components/ • Kubernetesクラスタが機能す るために必要なノード ・マスターノード ・ワーカーノード • 各ノードにはクラスターが機 能するためのコンポーネント が存在

5 ノード/コンポーネントはどうやって配置される？ Kubectl API server replication, namespace, serviceaccounts, etc. -controller- manager -scheduler etcd Master node Worker node kubelet kube-proxy Container Runtime Pod Pod Containers Containers Worker node kubelet kube-proxy Container Runtime Pod Pod Containers Containers Internet https://github.com/ivanfioravanti/kubernetes-the-hard-way-on-azure Kubernetes the hardway on Azureの場合 • マスターノードとワーカー ノード ⇒VMとしてコマンドで直接起動 ・コンポーネント ⇒ VMの中でSystemdに登録さ れた常駐プロセスとして起動

6 …OpenShiftは？

7 oc get pods –A を実行

8 実行結果からわかること ・OpenShiftのマスターノードコンポー ネントはコンテナ/Podとして動く (Systemdなどに登録された常駐プロセス ではない) ・OpenShift自身が管理 = Self Hosting Kubernetes

9 Self Hosting Kubernetesとは？ Proposal: Self-hosted Control Planeより抜粋 https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/self-hosted-kubernetes.md Kubernetesクラスターの必須コンポーネントとオプションコン ポーネントをKubernetes自体の上で実行すること Kubectl API server replication, namespace, serviceaccounts, etc. -controller- manager -scheduler Master node kubelet Container Runtime

10 メリット Proposal: Self-hosted Control Planeより抜粋 https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/self-hosted-kubernetes.md 1. ホスト(マスターノード)が必要なコンポーネントが 少なくなるのでインストール手順が簡素になる 2. デプロイメント方法(キッティング手順)が一貫性の ある操作で行える 3. イントロスペクション: Kubernetes APIを使用し て自分自身のデバッグを行える 4. クラスターのアップグレードをKubernetes APIを 介して行える 5. より簡単に高可用性な構成を組むことが可能になる

11 …ちょっと待ってください (これにたどり着いたときの自分の心の声)

12 APIサーバーのPodは そもそもどうやって デプロイしたか？

13 鶏と卵問題

14 ・StaticPodはkubeletが指定した所定のフォルダにyamlファ イルを置くとPodとして起動してくれる仕組み ・APIサーバーに接続できない状態でもkubeletに合わせて確実 に起動するのでログやVM等のAgentとして利用できる ※Static Podについて

15 OpenShift インストールツールで Self Hosting Kubernetesの実装を確認 してみましょう

16 説明の前に (免責事項) • OpenShift installer(OCP4.2.9)のmasterブランチのソース コードをリーディングした結果に基づいています • OpenShift on Azure(Managedではなく、インストールツー ルで構築できる方)で構築してログを観察した推察を含んでいま す • 解説者はJava, Ansibleと心中したいので、golang, Terraformについては詳しくありません。Logrusのメソッド をたくさん仕込んで動作を確認しましたが、説明等至らないこ とがあればご容赦ください。大きな誤りがあれば遠慮なくおっ しゃってください。

17 OpenShiftのインストレーションツールが内部で行っている処理 openshift-install create cluster bootstrap用VM master用VM 1. Bootstrap用VMとMaster ノード用VMを作成 • 作成されたVMには何もコン ポーネントはインストール されない • この時点ではWorkerノード 用VMは作成されない

18 OpenShiftのインストレーションツールが内部で行っている処理 Ignitionファ イル bootstrap用VM master用VM 2. Ignitionと呼ばれるプロビ ジョニングツールを利用した、 サービスの起動処理の実施 →次のページで詳しく説明し ます

19 Terraformの特性とIgnitionを利用する理由 • Terraformは構築後のVMにアプリケーションをインストール することをあまりお勧めしていない(ようだ) https://www.terraform.io/docs/cloud/run/install-software.html • OpenShiftインストーラーはこの問題？を次の設定で解決 • 予め必要なツールがインストールされたVHDを用意 https://github.com/openshift/installer/blob/master/data/data/rhcos.json • RHCOSの独自機能であるIgnition※を利用したSystemdのサー ビス起動 ※CoreOS Container Linux専用に設計されたプロビジョニング ユーティリティツール。ユーザースペースがブートを開始する前 (initiramfsで)に構成を完了することができる。 https://coreos.com/ignition/docs/latest/

20 OpenShiftのインストレーションツールが内部で行っている処理 bootstrap用VM 3. Ignitionにより kubelet.service, bootkube.serviceなどの サービスが起動 ⇒bootstrap用VMの中に 簡易版Openshiftを構成する

21 OpenShiftのインストレーションツールが内部で行っている処理 bootstrap用VM 4. bootstrap用VMの中に構成 された簡易版Openshiftは MachineConfigOperatorなど のマニフェストファイルを順番 にデプロイ、実行 • すでにVMがあるmaster用 VMには更にキッティングを 行い、必要なコンポーネント (apiserver, controller- manager, scheduller)は Operatorを通じて配置する • 存在しないworker用VMは作 成から行う master用VM worker用VM

23 OpenShiftのインストレーションツールが内部で行っている処理 bootstrap用VM 5. 下記の条件を確認後、bootstrap 用VMを削除 ・Serverのバージョン情報を取得で きること(oc get versionのServer 側と同じ情報) ・”bootstrap”configmap に”status: complete”が書き込ま れること master用VM worker用VM openshift-install create cluster

24 まとめ 1. OpenShiftのMasterノードのコンポーネントは OpenShift自身が管理している(Kubernetes Self Hosting) 2. OpenShiftのインストールツールはbootstrap用 VMの中に縮小版OpenShiftを作成し、構築対象 のOpenShiftのコンポーネントを配置している

25 参考資料 赤帽ブログ全般 https://rheb.hatenablog.com/ Openshift Installerリポジトリ https://github.com/openshift/installer/ OpenShift 4: Install Experience https://blog.openshift.com/openshift-4-install-experience/ Installation and update https://docs.openshift.com/container-platform/4.2/architecture/architecture- installation.html Bootkubeリポジトリ https://github.com/kubernetes-sigs/bootkube/