OPEN SHIFT IPI / UPI 解体新書 YUHKI HANADA あけおめ OpenShift.Run 2022 (#14) - connpass

OpenShift の基本的な構成のおさらい 2 master Infra Node AZ2 master Infra Node AZ1 master Infra Node AZ3 Cloud Service上 Worker Node Worker Node Worker Node Worker Node Worker Node Worker Node master Infra Node master Infra Node master Infra Node Worker Node Worker Node Worker Node Worker Node Worker Node Worker Node On premise 上 • 高可用性には、3本の Master Node が必要になります。 • “Infra Node” は、技術的には “Woker Node” と同じもので、OpenShift 用語です。 Monitoring, Logging や Local Container Registry などを “Infra Node“ にインストールする事が許可されています。 “Infra Node” は、“Worker Node”と違ってサブスクリプションは必要ありません。 Note: Low Latency ( Region 内) Data Center Low Latency All nodes are (usually) Virtual Machines Nodes could be Virtual or Physical

もう少し具体的に。AWS上にOpenShift を展開する場合のよくある構成 3 master worker worker AZ2 master worker worker AZ1 master worker worker AZ3 • OpenShift の Master Node は、3つの Node で冗長化を構成 する (多数決で正しいデータを持っている Node を決める） • AWS の AZ (Availability Zone) それぞれに、master node を配置する。 • リージョンの中の「独立した」「場所」が AZ [1]。 • 1つの AZが1つの DataCenter (複数の DataCenterである場 合いもある）DataCenter 間の遅延はほぼ無い (遅延は2ms ～ 1ms程度とされる[2]) • 「ap-northeast-1」リージョンであれば、 「ap-northeast- 1a」 「ap-northeast-1b」 「ap-northeast-1c」のような AZが存在する。 • リージョンは、「東京」「大阪」のようにもっと地理的に離れ た概念。 Tokyo リージョン (ap-northeast-1) [1] https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html [2] https://youtu.be/JIQETrFC_SQ?t=1078 AZは一般的な構成では遅延を気にしなくて良い近距離に設 置されている。 このビデオは AZ のLatency の考慮についていろい ろ語られて居て伝説となっているビデオです。

OpenShift のインストーラーの仕組み openshift-install (インストーラー・プログラム) • インストーラーが作成する Master Node 数、Worker Node 数等の構成 • Cluster の名前 • 使用するドメイン名 • Cluster が使用する Network 情報 • Cloud Prvoider のクレデンシャル情報 等など install-config.yaml (クラスターの構成情報等を記述する) 参照 インストール先のインフラ

IPI install 5 apiVersion: v1 baseDomain: mydomain.work compute: - architecture: amd64 hyperthreading: Enabled name: worker platform: {} replicas: 2 controlPlane: architecture: amd64 hyperthreading: Enabled name: master platform: {} replicas: 3 metadata: creationTimestamp: null name: ocp45-aws networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 machineNetwork: - cidr: 10.0.0.0/16 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: aws: region: ap-northeast-1 publish: External pullSecret: • AWS に IPI する時の典型的な install-config.yaml • All three nodes are deployed in different AZ in the same region (ap-northeast-1) • Specifying AWS zones is supported via compute.platform.aws.zones controlPlane.platform.aws.zones but each master node is deployed in different zones with default. compute: # compute nodes - platform {} # {} means default … controlPlane: # master nodes platform {} AWS Region ap-northeast-1 3 Master Nodes 2 Worker Nodes ap-northeast-1 (Tokyo) master worker master worker master AZ(ap-northeast-1a) result install-config.yaml AZ(ap-northeast-1b) AZ(ap-northeast-1c)

IPI と UPI UPI (User Provisioned Infrastructure) IPI (Installer Provisioned Infrastructure) openshift-install (インストーラー・プログラム) OpenShift OpenShift openshift-install (インストーラー・プログラム) User が別途作成する (User Provisioned) 作成対象 作成対象 Master Master Master Worker Worker Master Master Master Worker Worker OSのメディア レポジトリ レポジトリ

Full Stack Automation (IPI) Bare Metal OPENSHIFTのマルチプラットフォーム対応 7 ユーザーが自分で OpenShift を導入する場合でも、複数の種類のインフラの Platform をサポート IPI (Installer Provisioned Infrastructre) 方式のインストールでは、 OpenShift が稼働する Master /Woker Node から、全てインストーラーが作 成する。 Bare Metal 環境でも、BMC (Basedboard Management Controller)等を使用 して物理サーバーを自動で構築する。 UPI (User Provisioned Infrastructre) 方式のインストールでは、OpenShift が稼働 する Master /Woker Node の OSのインストールはユーザーが、手動で行う。それよ り上のレイヤーのインストールは、インストーラーが導入する。 As of OpenShift 4.9 OpenShift で検証済みの Pltaform OpenShift Container Platform 4.x Tested Integrations (for x86_x64) - Red Hat Customer Portal Nutanix AHV もサポート Red HatとNutanix、オープンハイブリッド/マルチクラウド ソリューションの提供に向けた戦略的パートナーシップを発表 Bare Metal IBM Power Systems Azure Stack Hub Pre-existing Infrastructure (UPI) 元絵は OpenShift What’s New より

Platform Integration とは？ 8 $ openshift-install explain installconfig.platform KIND: InstallConfig VERSION: v1 RESOURCE: Platform is the configuration for the specific platform upon which to perform the installation. FIELDS: aws AWS is the configuration used when installing on AWS. azure Azure is the configuration used when installing on Azure. baremetal BareMetal is the configuration used when installing on bare metal. gcp GCP is the configuration used when installing on Google Cloud Platform. ibmcloud IBMCloud is the configuration used when installing on IBM Cloud. kubevirt Kubevirt is the configuration used when installing on kubevirt. libvirt Libvirt is the configuration used when installing on libvirt. none None is the empty configuration used when installing on an unsupported platform. openstack OpenStack is the configuration used when installing on OpenStack. ovirt Ovirt is the configuration used when installing on oVirt. vsphere VSphere is the configuration used when installing on vSphere. $ apiVersion: v1 baseDomain: mydomain.work compute: - architecture: amd64 hyperthreading: Enabled name: worker platform: {} replicas: 2 controlPlane: < snip ! > networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: aws: region: ap-northeast-1 publish: External pullSecret: ******************* install-config.yaml ・platform.aws は、OpenShift Installer が AWS API を 使ってインストールする事を意味します。(integrated with AWS) ・platform.none は、“any platform (or platform agnostic) ” インストールを指します。この場合、 OpenShift をインストールする Node は事前に作成してお く必要があります。 openshift-install コマンドでも explain が使える

Platform Integration の実例 (VMWare の例) 9 Vmware UPI install-config.yaml サンプル Vmware IPI install-config.yaml サンプル apiVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker replicas: 0 controlPlane: hyperthreading: Enabled name: master replicas: 3 metadata: name: test platform: vsphere: vcenter: your.vcenter.server username: username password: password datacenter: datacenter defaultDatastore: datastore folder: "//vm//" fips: false pullSecret: '{"auths": ...}' sshKey: 'ssh-ed25519 AAAA...' Installing a cluster on vSphere with user-provisioned infrastructure - Installing on vSphere | Installing | OpenShift Container Platform 4.9 apiVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker replicas: 3 platform: vsphere: cpus: 2 coresPerSocket: 2 memoryMB: 8196 osDisk: diskSizeGB: 120 controlPlane: hyperthreading: Enabled name: master replicas: 3 platform: vsphere: cpus: 4 coresPerSocket: 2 memoryMB: 16384 osDisk: diskSizeGB: 120 metadata: name: cluster platform: vsphere: vcenter: your.vcenter.server username: username password: password datacenter: datacenter defaultDatastore: datastore folder: folder network: VM_Network cluster: vsphere_cluster_name apiVIP: api_vip ingressVIP: ingress_vip fips: false pullSecret: '{"auths": ...}' sshKey: 'ssh-ed25519 AAAA...' Installing a cluster on vSphere with customizations - Installing on vSphere | Installing | OpenShift Container Platform 4.9 クラスター内に、 LoadBalacer もデプロイさ れる。ここに指定した VIP が使われる。 インストーラーが、指定したリソ ースを持つ Core OS のノードを 作成する。 Nodes CPU / Memory は、ここでは指 定できない。 UPIの場合は、Nodeはユーザーが別途 準備する。 ここの情報を使って、インストール完 了後に、PVの作成が vCenter 経由で できるようになる。 VMware に OpenShift を導入する3つの方法 • IPI (CoreOS nodes + LB deployed by installer) • UPI (PV等の作成用に VMware API との連携) • any platform / platform agnostic installation (VMWare API との連携はしない。) vCenter へのアクセスを通して、 Node をデプロイする。 インストールが完了した後に、 PVの作成などもできるようにな る。

VMware 環境における Platform Integration 種別 VMWare 上へのインストールの場合、OpenShift Installer が行う作業 Platform Integration IPI • Master / Worker Nodeの作成 • Cluster 内 Load Balancer の作成 ( Master API / Userアプリ用) • OpenShift (Kubernetes + α) のインストール • デフォルトの Storage Class の作成 (PVの Dynamic Provisioning) 有り UPI • OpenShift (Kubernetes + α) のインストール • デフォルトの Storage Class の作成 (PVの Dynamic Provisioning) 追加手順で、MachineSet を作成する事もできる Any Platform Installation • OpenShift (Kubernetes + α) のインストール 無し • OpenShift Monitoring は、標準のインストールに含まれています。 • OpenShift Logging や、CI/CD ツール、Integrated Registry 等は OpenShift の標準インストールが完了後にインストール するコンポーネントです。 • あくまで現時点(OCP4.9)での VMWare の例であって、プラットフォームによって UPI / IPI によって作成される範囲は異な る可能性があります。 一般的に VMWare の IPI / UPI / Any Platform Installation と言う時に意味している範囲 (個人の見解) …… (OCP 4.9時点) Pltaform に よりこの親密 度が違う

Platform Integration “無し”とは？ 11 piVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker replicas: 0 architecture : ppc64le controlPlane: hyperthreading: Enabled name: master replicas: 3 architecture : ppc64le metadata: name: test networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: none: {} fips: false pullSecret: '{"auths": ...}' sshKey: 'ssh-ed25519 AAAA...' Installing a cluster on IBM Power Systems - Installing on IBM Power Systems | Installing | OpenShift Container Platform 4.9 IBM Power System apiVersion: v1 baseDomain: example.com compute: - hyperthreading: Enabled name: worker replicas: 0 controlPlane: hyperthreading: Enabled name: master replicas: 3 metadata: name: test networking: clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 networkType: OpenShiftSDN serviceNetwork: - 172.30.0.0/16 platform: none: {} fips: false pullSecret: '{"auths": ...}' sshKey: 'ssh-ed25519 AAAA...' Installing a cluster on any platform - Installing on any platform | Installing | OpenShift Container Platform 4.9 Installing a cluster on any platform install-config.yaml install-config.yaml

Any Platform installation ( Platform Agnostic installation) • インストール先の基盤に完全に依存しない方法。環境に依存に依存する部分が無いインストール方法。 • Platform Agnostic installation という呼び方と同義 Infra Structure (Physical or Vitual) User アプリケーション Master Nodes Worker Nodes API 連携無し AWS, VMware の APIや、BMC(Baseboard Management Controller) 等と の連携がない

インストール方法の呼び方のまとめ 13 1) IPI (Master / Woker Nodes are created by installer) - Platform の API と連携がある (Node の Provisioning 等に使用) 2) UPI (Master / Worker Nodes are created by user) - Platform の API と連携がある (PVの Provisioning 等に使用でき る) - Platform の API と連携が無い Any Platform Installation (or Platform Agnostic ) 3) Assisted Installer Installation (Tech Preview @ OCP 4.9) インターネットに接続できる環境でのみ使用できる手法 インストーラーをクラウドサービスとして提供している。 openshift-install コマンドを使用 構成は install-config.yaml で管理。 SaaS installer (console.openshift.com) Any Pltaform Install を、UPI と区別しているケース もある。UPIと Any Platform の定義の境界は、現状 では曖昧になっている。 UPI と言った時に曖昧さは残るが、Any Platform Installationと言った時には曖昧さは残らない。 インストーラーがクラウド上にあるので、インストーラー を実行する端末が必要ない。 厳密に言うとＩＰＩに含まれる？ 今の所、別建てで扱う事が多いように見える(個人の感想)

表現が難しい例 「OpenShift をベアメタル UPI インストールします」 よく見かける言い方で、間違いでは無いですが「”ベアメタル UPI “という言い方はしない方がいい」と いう意見があります。 この場合の主張は「UPI」は多少なりとも Platform との Integration を含んでいる という、考えに基 づいてます。 もしインストール時に「Platform Integrationを全くしない」事を意味したいのであれば「Any Platform Installationでインストールする」などの言い方をして明確化すると良いと思います。

最近のIPIの傾向。VMWare IPI の ロードバランサー Master nodes Worker nodes Master nodes Worker nodes VMWare IPI UPI / Any platform installation 別途設置の Load Balancer (Haproxy等) *.apps.ocp48.example.localdomain (アプリ用のドメイン) keepalived keepalived keepalived keepalived keepalived keepalived VIP VIP api.ocp48.example.localdomain (API Serverアクセス用ドメイン) *.apps.ocp48.example.localdomain (アプリ用のドメイン) api.ocp48.example.localdomain (API Serverアクセス用ドメイン) 参考：OpenShift 4.8 を vSphere 上にIPIインストールする MCO (Machine Config Operator) が、keepalived を static pod としてデプロイするように書かれている API Server Endpoint API Server Endpoint Ingrees Endpoint Ingrees Endpoint IPI = 内部ロードバランサーが作成される。わけではなく、現状(OCP4.9) では Vmware IPIと Baremetal の IPIのみ。 OpenShift 4.9 時点

Thank you