OpenShift と Kubernetes の違い

セミナー資料
お手数ですが、資料中リンクはダウンロードしてクリックしてください。

こちらのセミナーを元にしたブログ版もあります。(一部内容違います)

IBM Cloud Blog 第5回『Red Hat OpenShift と Kubernetes の違い』
https://www.ibm.com/blogs/solutions/jp-ja/container-cocreation-center-05/

Transcript

1. OpenShift と Kubernetes の違い 1 2021/11/02 Cloud Solution Architect Yuhki Hanada
2. OpenShift と Kubernetes の違い 2
3. Kubernetes を本番運用するために必要なもの CNI plugin Ingress CSI plugin Server / virtualization environment Linux OS Monitoring Backup Software サポート Service Mesh Container Registry CI / CD tool Security tool Container Base Image Application Library (Language/ basic middleware) 開発・運用ツール Multi Cluster Management DNS /DHCP Container ランタイム コンテナを動かすために最低限必要なもの Storage Load Balancer Kubernetes 側で規格だけ決めているもの 3
4. Kubernetes を本番運用するために必要なもの CNI plugin Ingress CSI plugin OpenShift Data Foundation Server / virtualization environment Linux OS Monitoring Backup Software 提供製品に対するサポート Service Mesh Container Registry CI / CD tool Security tool Container Base Image (UBIサポート) Application Library (Language / Basic middleware) 開発・運用ツール Multi Cluster Management Container ランタイム コンテナを動かすために最低限必要なもの Storage OpenShift Container Platform に含まれているもの Red Hat の Option 製品として用意されているもの Advanced Cluster Management OpenShift Data Foundation Advanced Cluster Security DNS /DHCP Load Balancer 4
5. OpenShift と Kubernetes の違い Cluster services monitoring, registry, logging Application services middleware, functions, ISV Service mesh Developer services dev tools, automated builds, CI/CD, IDE Enterprise Linux CoreOS Kubernetes OpenShift Container Platform Red Hat Support 開発・運用コンポーネント Kubernetes 環境を導入するためのOS ＋ ＋ ＋ Kubernetes 機能拡張 ocコマンド,OTA, Router (Ingress) , OpenShift Virtualization, Security コンテナのベースイメージ + SWライブラリ PHP, Python, Perl, Ruby, Node.js,, MariaDB, MongoDB, MySQL, PostgreSQL etc ＋ ＋ 5
6. Cluster services monitoring, registry, logging Application services middleware, functions, ISV Service mesh Developer services dev tools, automated builds, CI/CD, IDE Enterprise Linux CoreOS OpenShift Red Hat Support 開発・運用コンポーネント Kubernetes 環境を導入するためのOS ＋ ＋ ＋ Kubernetes 機能拡張 ocコマンド,OTA, Router (Ingress) , OpenShift Virtualization, Security コンテナのベースイメージ + SWライブラリ PHP, Python, Perl, Ruby, Node.js,, MariaDB, MongoDB, MySQL, PostgreSQL etc ＋ ＋ Kuberetes コア単体では足りない部分の補強 1) Kubernetes がプラグインを前提として本体に機能を持ってない部分 2) 実際の運用要件では足りない部分の機能拡張、追加機能。 (専用UI、セキュリティ、テンプレート、OpenShift Virtualization,etc) アプリケーションを作成するのに必要な、ライブラリ類 PHP, Python, MySQL, Postgre 等の基本アプリケーション 運用ツール群 監視、ログ収集、サービスメッシュ監視、CI/CDのための開発ツール Kubernetes の Master Node / Worker Node 用の OS Kubernetes 環境をホストするためのコンテナ専用OS (CoreOS) OpenShift 4.8 時点で RHEL 8.4ベース OpenShift と Kubernetes の違い RHEL由来
7. Red Hat OpenShift Container Platform Kubernetes 使用時の選択 7
8. Cloud Native Landscape 課題： ・同じカテゴリーに同じ ような事ができるツール がたくさんある。 ・全てのツールを把握す る事は不可能。 ・Enterprise で安心して 使用できそうなものがど れかわからない。 ・仮に良さそうなツール を選択して組み合わせた としても、/ サポートし ているベンダーが日本に いない / 問い合わせ先が バラバラになる/ 自分で サポートできるわけでな し… 8 出典：CNCF Cloud Native Interactive Landscape
9. Cloud Native Landscape 課題： ・同じカテゴリーに同じ ような事ができるツール がたくさんある。 ・全てのツールを把握す る事は不可能。 ・Enterprise で安心して 使用できそうなものがど れかわからない。 ・仮に良さそうなツール を選択して組み合わせた としても、/ サポートし ているベンダーが日本に いない / 問い合わせ先が バラバラになる/ 自分で サポートできるわけでな し… OpenShift に含まれ、サポート付きで提 供されるコンポーネント(一部) 9 出典：CNCF Cloud Native Interactive Landscape
10. Kubneretes を使う時にしなければいけない選択(1) クラスターのネットワーク用のCNI対応のプラグイン | Kubernetes より抜粋 • Big Cloud Fabric (Big Switch Networks) • Calico • Cilium • CNI-Genie (Huawei) • Coil • Contrail / Tungsten Fabric • Flannel • Jaguar • k-vswitch • Knitter • Kube-OVN • Kube-router • NSX-T (VMware) • OpenVSwitch • OVN(Open Virtual Networking) • Romana • Weave etc… eth0 Pod Pod eth0 Node 間の物理ネットワーク eth0 eth0 クラスターネットワーク(仮想ネットワーク) Linux Bridge Linux Bridge veth veth ユーザーが選択して クラスターネットワーク用にKubenretes に組み込む ・Kubenretes 本体は、コンテナ間のクラスターネットワークを提供しない。 ・CNI (Countainer Network Interface) というインターフェースを定義 し、そこに3rd Partyが作成した仮想ネットワーク用のプラグインを使用する。 ・ユーザーが、CNI対応のプラグインを選択 ・OpenShift の場合は、「OpenShift SDN」と「OVN」と呼ばれるプラグイ ンが提供されている。(OVNに移行していく予定) ・提供元はそれぞれ違う ・サポートベンダーの有無もそれぞれ ・入手方法もそれぞれ 10
11. Kubneretesを使う時にしなければいけない選択(2-1) Kind 一般的な呼び方 説明 Ingess Ingress (Ingress Controller や、それによって 処理される Ingress リソース (kind: Ingress) をまるっと指す) HTTP/HTTPSのアプリケーションを外部に公開する方法 L7アプリケーションをクラスターの外に公開 Service type = NodePort (Service の type が NodePort) 各 NodeのIPと静的なポートを使って「Serivce」を公開する。 L4 アプリケーションをクラスターの外に公開 Service type =LoadBalancer (Serivce の type が LoadBalancer) IaaS Cloud Provider の ロードバランサーを使用して 「Service」 を公開する。 実装そのものは、Cloud Providerによって異なる。 L4 アプリケーションをクラスターの外に公開。 Service 他にも… [1] Kubernetes 側で type=LoadBalancer を作成してまおうとするプロジェクトもある MetalLB, bare metal load-balancer for Kubernetes (universe.tf) アプリケーション(Pod) は、プライベートIPしかもっておらず、クラスター外部に公開するには、クラスター 外部の IPに紐付けて公開を行います。その方法には幾つかの方法があります。 Kubernetes 外部の仕組みと連携 するので、基本的[1]に AWS/GCP/Azure/IBM等の Cloud Providerのみが実装 Kubernetes 単体で構成できる Ingress を実現する実装が複数あ りユーザーが選択 11
12. 補則：L3/L4とL7 階層 名称 代表的なプロトコル、規格 Layer 7 アプリケーション層 HTTP, DNS, SMTP, POP Layer 6 プレゼンテーション層 TELNET Layer 5 セッション層 TLS Layer 4 トランスポート層 TCP / UDP Layer 3 ネットワーク層 IP、ICMP、ARP Layer 2 データリンク層 Ethernet Layer 1 物理層 ケーブル、無線 OSI 参照モデル HTTP1/2 HTTP TLS TCP IP Ethernet 実際の実装例 Ingress がトラフィックを 割り振るために見ている部分 Service がトラフィックを 割り振るために見ている部分 (TCP/IP ならIPアドレスと 使用Port) 現在は、殆どのアプリケーション通信が HTTPベースになっている。 一般的な Firewall であれば、通常 HTTPを通すようになっており、大半の環境で通信できる。また、TLSも広く普及した技術となって おり脆弱性が発覚した時の対応も安心感がある。 12
13. 補則：Pod を外部に公開する方法 Ingress Service (type=Node Port) Service (type = LoadBalancer) LoadBalancer LoadBalancer LoadBalancer Ingress Pod Pod Pod Pod Ingress Pod 80/443 80/443 35000 35000 35000 ユーザーが別途用意 IaaS Provider が自動構成[1] 外部IPも指定可能 Pod Pod Pod Deployment Deployment Deployment Cluster 内部のPod間でのロードバランスは行われる Worker Node レベルのロードバランスは、Kuberentes の外部で設定する。 Worker Node レベルのロードバランスも、 Kuberentes のリソースを作ると自動で設定 される。 Ingress の実 装は他にもパ ターンがある。 Cluster外の L7 LB+Node Portを組み合 わせたものも ある。 各Nodeの 同じPort が、一つ のアプリ につなが る Kubernetes として提供するアプリケーションへの入り口 13 [1] 基本的に AWS/Azure/GCP/OpenStack の外部インフラに依存する。が、Kubernetes 側で type=LoadBalancer を作成してまうプロジェクト もある MetalLB, bare metal load-balancer for Kubernetes (universe.tf) NodePort が 作成される (kind内で Port指定も 可能) L7 L4 L4
14. Kubneretesを使う時にしなければいけない選択(2-2) • AKS Application Gateway Ingress Controller AKSで使用可能 • Ambassador API Gateway Envoyベースの Ingress Controller。Datawire によるサポート提供。 • Voyager HAProxyベース。AppsCode Inc によるサポートと保守提供 • AWS ALB Ingress Controller AWS Application Load Balancer ベース。 • Contour Envoyベース。VMware • ハードウェア(MPX）、仮想化(VPX)、フリーコンテナ化(CPX) ADC用のIngressコントローラー Citrixによる提供 • F5 BIG-IP Container Ingress Services for Kubernetes F5によるサポートと保守提供。 • Gloo Envoyベース。solo.ipがエンタプライズサポート提供 • HAProxy Ingress HAProxy Technologies によるサポートと保守の提供。 • Control Ingress Traffic Istioベース。 • Kong Ingress Controller for Kubernetes Kong によるサポートと保守の提供。 • NGINX Ingress Controller for Kubernetes Nginx によるサポートと保守提供 • コミニティ版 Nginx Ingress Controller Kubernetes プロジェクトによって保守されている Nginx Controller (商用版と機能が違う) ・提供元はそれぞれ違う ・サポートベンダーの有無もそれぞれ ・入手方法もそれぞれ Ingressコントローラー | Kubernetes より抜粋 Ingress リソースを処理するための Ingress Controller は複数の選択肢があります。 OpenShiftは、Red Hat が提供する HAProxy ベースの Ingress Controller を 同梱
15. Kubneretesを使う時にしなければいけない選択(3-1) 15 OS OS OS OS OS OS etcd kube-scheduler kube-apiserver kube-dns OS OS OS User のアプリケーション コンテナ コントロール・プレーン コンテナ ユーザー・アプリケーション コンテナ Router 監視 Logging Registry 運用コンポーネント コンテナ OS Kubernetes Cluster Kubernetes 自体には含まれてないので、 ユーザーが、各コミニュティ/ベンダー が提供している複数あるコンテナ・ラン タイムから選択 Kubernetes を動かすための Node の OS と、コンテナを稼働させるための Runtime はユーザーが選択する。 OpenShift のパッケージに CoreOS も含まれる Enterprise Linux CoreOS • dockershim • • • • • コンテナ・ランタイム コンテナ・ランタイム (CRI / OCI Runtime)
16. Container Runtime CRI (Container Runtime Interaface) [1] • containerd • CRI-O ( included in CoreOS) OCI (Open Container Initiative) Runtime • runC ( included in CoreOS) • gVisor • Kata Containers Low-Levl Container Runtime High-Level Container Runtime Pod (Container) Kubernetes (kubelet) Kubneretesを使う時にしなければいけない選択 (3-2) 16 CRI (Container Runtime Interface) イメージの Pull ファイルシステムの準備 PodのNICの作成 コンテナの作成、削除 [1] Chapter 5. Red Hat Enterprise Linux CoreOS (RHCOS) OpenShift Container Platform 4.9 | Red Hat Customer Portal
17. Red Hat OpenShift Container Platform 開発・運用ツールの選択 17
18. Cloud Native Landscape 課題： ・同じカテゴリーに同じ ような事ができるツール がたくさんある。 ・全てのツールを把握す る事は不可能。 ・Enterprise で安心して 使用できそうなものがど れかわからない。 ・仮に良さそうなツール を選択して組み合わせた としても、/ サポートし ているベンダーが日本に いない / 問い合わせ先が バラバラになる/ 自分で サポートできるわけでな し… OpenShift に含まれ、サポート付きで提 供されるコンポーネント(一部) 出典：CNCF Cloud Native Interactive Landscape
19. Automated operations Enterprise Linux CoreOS 19 コンテナの運用・アプリ開発に必要なコンポーネント コンテナの運用には、監視ツールやログ収集だけでなく、コンテナを保管するためのレジストリや、コンテナビルドの自動化のためツー ルを付属 クラスター運用サービス クラスタ管理を容易にし、運用業務を自動化するサービス Physical Virtual Private Public Any infrastructure 開発者向けツール 開発者がコンテナアプリケーション開発に集中できる環境を整えるサービス Cluster services monitoring, showback, registry, logging Application services middleware, functions, ISV Service mesh Developer services dev tools, automated builds, CI/CD, IDE certified アプリケーション関連サービス マイクロサービス間の連携やファンクションサービスを実現を支援するサービス ログ収集 レジストリ 監視 ISV Middleware サーバレス用の 機能 ServiceMesh IDE CI/CD Developer Tools Build fast. Ship first. Tekton ArgoCD Knative fluentd Operator Hub Istio Prometheus Image Registry IDE用プラグイン
20. Red Hat OpenShift Container Platform RHEL ベースのコンテナ開発 20
21. コンテナと RHEL CoreOS Linux Kernel コンテナの実行に必要なモジュール Linux Kernel コンテナの実行に必要なモジュール RHEL 7 固有の部分 (使用されない) Linux A ミドルウェア ユーザーアプリ RHEL7 UBI RHEL7 ミドルウェア ユーザーアプリ Linux B ミドルウェア ユーザーアプリ Linux A ミドルウェア ユーザーアプリ UBI RHEL7 ミドルウェア ユーザーアプリ Linux B ミドルウェア ユーザーアプリ ②Red Hat の提供するミドルウェ アライブラリを使用した場合のサ ポート範囲 Red Hat に よるサポー ト提供範囲 通常のOSを Host に使用した場合 ①コンテナ専用OSのエンタイトルメントが OpenShiftに付属 OpenShift には CoreOS や、ミドルウェア・ライブラリのエンタイトルメントも含まれているため、UBIイメージを使用する事で OSレ イヤーからミドルウェアまでの一括したサポートを受ける事ができます。 ③ UBIは再配布可能で通常サ ポートは無いが、OpenShift 上で使うとサポートあり RHEL CoreOS アタック サーフェ スの削減 21 コンテナの RHELバージョンと Node の バージョンの組みあわせのサポートについて：Red Hat Enterprise Linux Container Compatibility Matrix - Red Hat Customer Portal
22. コンテナの「ベース・イメージ」 UBI Micro UBI Minimul UBI Standard (Platform) UBI Multi-service ※1) サイズは、資料作成時点での参考値。 ubi (72.1MB(※1)) ubi-minimal (37.6MB(※1)) ubi-init (76.4MB(※1)) Red Hat が提供する RHEL ベースのコンテナのベース・イメージ ubi-micro (12.9MB(※1)) コンテナ作成のための RHEL ベースの「ベース・イメージ」をオンラインで提供。 Docker Hub Red Hat Ecosystem Catalog 22
23. Red Hat OpenShift Container Platform エンタープライズ向けの追加機能 23
24. 実運用のための拡張機能例 24 • SCC (Security Context Constrain)[1] Namespace 単位で root権限を制限したり(デフォルト)、使用する SELinux context、secomp profile等を設定する機能。この機能 を使用して、OpenShift は、デフォルトでは、rootless の Podしか実行できない設定になっておりセキュリティを高めてます。 Kuberenetes の同様の機能である PSP (Pod Security Policy)は、1.21 (April 2021)でGAに至らずにDeprecated 1.22から、後継となる PodSecurity Admission のアルファがはじまっています。 • Project / Template [2] Project (= Namespace の拡張) を実装。デフォルトで Project を作成する時に、Template に定義された デフォルトの LimitRange / ResourceQuota / NetworkPolicy / RBAC を適用し、自動でNamespace 毎のリソースの使用制限を適用できます。 例えば、この機能により、Project 作成時の管理者による Limit Range / NetworkPolicy 等の個別制限適用の手間を省く事ができま す。 • ClusterResourceQuota[3] 同一ラベル、アノテーションを持つ複数のプロジェクトを統合して Quota を設定するためのオブジェクト。複数のプロジェクトをま たいで作成できるオブジェクトの数を制限したい時に使用できます。 • EgressNetworkPolicy(OpenShift SDN)[4] / EgressFirewall(OVN-Kubernetes) [5] (※1) Cluster外部のホストやサブネットに対する Pod のアクセス許可/不許可を設定。Pod を特定のホストにしかアクセスさせたくないよ うな要件で使用できます。 OpenShift では、実際の Kuberentes 運用であると便利な機能を追加機能として提供しています。 ※1 ) OpenShift 4.8時点で CNI としてOpenShift SDN か、ONV-Kubernetes かが選択できる。kind: EgressFirewall は、OVN コミニュティの OVN-Kubernetes レ ポジトリで開発されている Custom Resource. この資料では青字のみ追加説明
25. 実運用のための拡張機能例 25 • Egress Router Pod (OpenShift SDN)[6] / EgressIP (OVN-Kubernetes)[7] 等の ソース IP 固定機能(※1) Podから外部の宛先にアクセスする場合のソースIPアドレスを、決まった IP に固定する機能。Cluster外部のサービスが特定のIP からのアクセスしか許可してないような構成時に使用できます。(AWS/Azure 等の Cloud Providerでは 構成により機能制限があ る場合があります) • Over The Air Update [8] UI、もしくはCLIの一度の操作だけで、Clusterのアップデートを自動で順番を守りながら実行する機能。 Kubernetesでは、コンポーネント毎に順番を守りつつ、各ノードを一つづつアップグレードしていく必要がありますが、 OpenShift では、OpenShiftが独自に追加したコンポーネントや、Node も含めてワンクリックで自動アップデートを行う事ができ ます。また OpenShift (Kubernetes 含む)部分の更新と連動して、Node の OS (CoreOS) の更新も行えるようになっています。 • MachingeConfig Operator [9] Kubneretes としては管理外の扱いである、Node のOSもを、OpenShift側から管理する機構です。 新しい Node を追加した時に他の Nodeと同じ構成の Node を自動構成してくれます。 • Image Stream [10] OpenShift で追加されている Image のタグ付け方法です。通常、image:latest のような同じ「コンテナ:タグ名」のままコンテナ を更新しても、名前が同じであると Deployment 等の更新は発生しませんが、Image Stream を使う事で、同じ「コンテナ:タグ 名」でもコンテナイメージのハッシュ値をチェックしてコンテナイメージを更新させる事ができます。 • OpenShift Web Console [11] たくさんある OpenShfit の機能を使いこなせるように、専用の Web User Interface を提供しています。管理者向け、開発者向け の Interface がそれぞれ用意されています。 ※1) 機能の区分けが複雑なので詳細はマニュアルを参照下さい。サポートの制限はありますが、Egress Router Pod は、OVN-Kuberentes でも使用できます。 この資料では青字のみ追加説明
26. SCC (Security Context Constraints) default では、”restricted” が適用される。 変更するには、cluster-adimin group の権限 (Cluster 管理者) が必要 root は使用不可 任意の UID で起動 標準で用意されている SCC Pod の起動を行うService Account に紐付ける project (namespace) cluster の管理者が管理 project の管理者が管理
27. Default の SCC SCC Description anyuid Provides all features of the restricted SCC, but allows users to run with any UID and any GID. hostaccess Allows access to all host namespaces but still requires pods to be run with a UID and SELinux context that are allocated to the namespace. hostmount-anyuid Provides all the features of the restricted SCC, but allows host mounts and running as any UID and any GID on the system. hostnetwork Allows using host networking and host ports but still requires pods to be run with a UID and SELinux context that are allocated to the namespace. node-exporter Used for the Prometheus node exporter. nonroot Provides all features of the restricted SCC, but allows users to run with any non-root UID. The user must specify the UID or it must be specified in the manifest of the container runtime. privileged Allows access to all privileged and host features and the ability to run as any user, any group, any FSGroup, and with any SELinux context. restricted Denies access to all host features and requires pods to be run with a UID, and SELinux context that are allocated to the namespace. This is the most restrictive SCC and it is used by default for authenticated users. OpenShift の default は、「restricted」 ホストへのアクセスは禁止。SELinux も有効がデフォルト 27
28. Project と Template ・・・・ metadata: creationTimestamp: null name: admin namespace: ${PROJECT_NAME} roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: admin subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: ${PROJECT_ADMIN_USER} - apiVersion: v1 kind: ResourceQuota metadata: name: project-quota namespace: ${PROJECT_NAME} spec: hard: count/pods: 10 limits.cpu: 6 limits.memory: 16Gi requests.cpu: 4 requests.memory: 8Gi requests.storage: 20G - apiVersion: v1 kind: LimitRange metadata: name: project-limits namespace: ${PROJECT_NAME} spec: limits: - default: cpu: 1 memory: 1Gi defaultRequest: cpu: 500m memory: 500Mi type: Container - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-ingress namespace: ${PROJECT_NAME} spec: ingress: - from: ・・・・ Project用のTemplate • project の 作成ユーザー名を annotation に銘記 • project の 作成ユーザーに、デ フォルトで用意してあるadmin ClusterRole に紐付け (RoleBinding) • Resource Quota の適用 • LimitRange の適用 • NetworkPolicy の適用 • etc… 基本設定のされた project template の 自動適用 project の作成 namespace の作成 RoleBinding 制限の無い namespace 個別に必要な設 定を手動で適用 Resource Quota LimitRange NetworkPolicy [1] サンプル Template openshift-toolkit/default-project-template.yaml at master · redhat-cop/openshift-toolkit (github.com) 28
29. アウトバウンドのソースIPの固定機能 Pod 外部サービス Pod からクラスター外部のサービスに対するソースIP Addres を固定 OpenShift Cluster ※ Egress Router Pod も 「EgressIP」リソース も、Cloud Provider 環境では、Cloud Provider のネットワーク機能制限があり、基本的に使用できない。 「NetNamespace」 という別のカスタム・リソースを使うと、Cloud 環境でも プロジェクト単位に Egress IP Address を固定できる。 出口は固定IP ・実装方式は、Egress Router Pod を使うか 「EgressIP」リ ソースを使うかによって、大きく異なる。 ・Egress Router Pod を使用する場合は、redirect mode / HTTP Proxy Pod / DNS proxy mode の 3つの動作形式があ る。 ・複数の方式があり、環境によって Support される方式が違 い、さらにそれぞれの方式により動作も異なるので注意。 Pod 29
30. OTA(Over The Air) Update アップグレード可能なパスを提示します。 UI / CLIで簡単にクラスターをアップデートします。 fast-4.4 fast-4.5 stable-4.5 現在のチャネル 次のチャネル チャネル毎のアップグレード可能なパス ※CLIからのアップデートも可能 $oc adm upgrade --to=<version> ※ fast / stable のチャネルはサポートがありますが、 candidate はサポートがありません。 ※ stable チャネルは、field からの報告を元に安定版と判 定されたものが表示されます。 30
31. Cluster Resource Quota Quotaを複数プロジェクト間で共有できるOpenShiftの Custom Resource。 一つの ClusterResourceQuota で、100以上のプロジェクトが関係する場合は、API serverに影響が出 る場合があるので注意する • Multi-Project Quota • ClusterResourceQuota リソースで定義できる • 選択された Project のリソースが合算され、合算値が使用リソースを 制限するために使われる。 • Project 管理者は、ClusterResourceQuota の作成権限は無いが、自 分の Project にかけられている制限を見る事ができる。 使用例：特定ユーザーの作成した Project を合算してリソースの使用制 限をかける。 Resource quotas across multiple projects - Quotas | Applications | OpenShift Container Platform 4.8
32. OTA (Over The Air Update) 現在のバージョンから、安全にアップグレード可能な選択肢を提示し、ク リック一つで、クラスターをアップデートします。 アップグレード可能なパスのみ提示 アップグレード・ボタン をクリックするだけ Kubernetes のバージョンアップ Kubernetesバージョンとバージョンスキューサポートポリシー | Kubernetes OpenShift のバージョンアップ コンポーネントや構成によって考慮点が変わる コンポーネントの既存のバージョンを確認し、アップ グレードを計画 ・ノード毎に一つ一つアップデート ・Master / Worker Node の OSは別管理 32
33. Over The Air Update の範囲 OS OS OS OS OS OS etcd kube-scheduler kube-apiserver kube-dns OS OS OS User のアプリケーション・コンテナ (Worker Node) OS OpenShift の コンテナ (Master Node) OpenShift Logging などの デフォルトの運用管理用のコンテナ Enterprise Linux CoreOS 「Over The Air Update」で更新される部分 Nodeの OSの管理を、別途ケア しなくても良い。(CoreOSを使 用した場合) • Kubernetes 本体 • OpenShift が追加したコンポーネント • Core OS 全てがアップデートの対象 (OpenShift として統合テストされている) 33
34. Red Hat OpenShift Container Platform サポート 34
35. Kubernetes のリリースサイクルの変更 • 2020年の2つ目のリリースである1.19 はCOVID-19 が有 り、通常よりもリリースの間隔が開く。それ以降のスケ ジュールがずれはじめる。 • Kubernetes 1.22 ( 2021 年 8月 GA) からは新しいスケ ジュールでリリース[1] • リリースは年3回へ[1] (以前は年4回) • 1.19以降は、1 year のサポート Window [2] 2021 年のリリース・スケジュール 1.21 (April, 08) 1.22 (August, 08) 1.23 (December, 07 予定) 2022 年のリリース・スケジュール 1.24 (April,12 予定) 1.25 (August, 09 予定) 1.26 (December, 06 予定) Kubernetes OpenShift 1.19 (2020/08/26) 4.6 (2020/10/27) 1.20 (2020/12/08) 4.7 (2021/02/24) 1.21 (2021/04/08) 4.8 (2021/07/27) 1.22 (2021/08/04) 4.9 (2021/10/18) [1] Kubernetes Release Cadence Change: Here’s What You Need To Know | Kubernetes [2] Kubernetes 1.19: Accentuate the Paw-sitive | Kubernetes 35 As of 2021/11/16
36. OpenShift Container Platform v4 LifeCycle (New) OpenShift 4.7 以降では全てのマイナーバージョンで • GA日から約6ヶ月のフルサポートがあります。(※1) • フルサポート終了後は、約12ヶ月のメンテナンスサポートがあります。(※2) • 上記を合算して、合計18ヶ月 (フル + メンテナンス) のサポートの期間が提供されます。 [1] How to open a PROACTIVE case for patching or upgrading Red Hat OpenShift Container Platform - Red Hat Customer Portal 参考1: LifeCycle ポリシーに関する公式ドキュメント：https://access.redhat.com/support/policy/updates/openshift 参考2: Lifecycle 変更に関するブログ (2021/10/18)：Time Is On Your Side: A Change to the OpenShift 4 Lifecycle (redhat.com) OpenShift 4.8以降は、偶数のマイナーバージョン(例:4.8, 4.10, 4.12) をEUS(Extended Update Support)として扱います。 4.8以降のEUSバージョンでは、 Worker Node に関しては、EUSバージョン間の直接のアップグレード手順が提供され、ユーザーアプリにあたえるリ ブートなどの影響を最小にする事が可能です。 また Premium Support では、Upgrade の4日以上前であれば、「プロアクティブ・ケース」 [1]を上げて Support と事前の情報共有を行う事が可能 です。 ※1) もしくは、次のマイナーバージョリリースのGAの90日後と比較して長い方。 ※2) フルサポートの期間が6ヶ月を超える場合は、フルサポート + メンテナンスサポートの合計が 18ヶ月になるように調整されます。 As of 2021/11/16 36
37. Red Hat OpenShift Container Platform OpenShift の構成 37
38. インフラ・ワークロード (router / monitoring等) 38 OpenShift と外部インフラの境界 Master nodes Workers API Server Controllers ユーザーワークロード Load Balancer DNS Server Persistent Volume ID管理 インフラ・ワークロード (router / monitoring等) CSI Plugin Master nodes Workers API Server Controllers ユーザーワークロード Persistent Volume CSI Plugin LoadBalancer Ingress 独自サービスと結合する ためのtoken の世界 提供の サービス CNI Plugin OpenShift は、ベンダーニュートラルが前提 使いやすくするために独自インフラと結合しているケース 初期構成が必要 Node 追加時に設定追加 Kuberentes リソース として、Kubernetes から API経由で構成 Ingress クラスタ外部に張り 出すタイプのIngress もある Cloud Provider 等の 実装が前提 オンプレでもクラウドでも同じ運用管理 境界線(疎結合) CNI Plugin 自社インフラのみ想定した Plugin のケースも OpenSfhit SDN / OVN Ingress
39. Managed and Engineered by Red Hat & IBM Red Hat OpenShift on IBM Cloud (RHOIC) OpenShift - Self Managed Cloud Platform Vendors OpenShift- Self Managed OpenShiftのマルチプラットフォーム対応 39 オンプレミス (ベアメタル/VMware/ RHV/ Nutanix / OpenStack) Azure Red Hat OpenShift (ARO) Managed by Red Hat & Azure OpenShift- Self Managed OpenShift- Self Managed ユーザーの自 主運用(※3) Red Hat が運用主体 (※1) クラウドベンダ との共同運用 (※2) OpenShift Dedicated Managed By Red Hat Red Hat OpenShift Service on AWS (ROSA) Managed by Red Hat & AWS OpenShift – Self Managed 対応環境の違い OpenShift は、Open な性質を生かして、様々な環境に対応しています。 様々なのクラウドプロバイダー上でも、Kuberentes サービスとして使用されています。 運用主体の違い OpenShift Dedicated Managed By Red Hat OpenShift- Self Managed Cloud Platform Vendor の各種 サービス ※1) クラウドベンダーの Platform 上に RedHatが OpenShift をインストールし、Managed サービスを提供する形態 ※2) クラウドベンダーのサービスとして販売されており、クラウドベンダーと Red Hatで共同運用されているもの。 ※3) ユーザーが自分でクラウドベンダー上に OpenShiftをインストールする方法 Managed Service
40. Full Stack Automation (IPI) Pre-existing Infrastructure (UPI) Bare Metal IBM Power Systems Bare Metal OpenShiftのマルチプラットフォーム対応 ユーザーが自分で 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 もサポート と 、オープンハイブリッド マルチクラウド ソリューションの提供に向けた戦略的パートナーシップを発表 40
41. 41 Master Master Worker Worker PV用ストレージ DNS サーバー 外部向け LB 内部向け LB DHCP サーバー ID管理 サーバー OpenShift Cluster ※ネットワークの構成、周辺サーバーの配置はあくまで一例です。 OpenShift 構成サンプル ロードバランサー 周辺サーバー PV用ストレージ OpenShiftクラスター外からの • ユーザーアプリ • マスターへのアクセス のロードバランス OpenShift クラスター内からの • マスターへのアクセス のロードバランス Worker Node は追加する事ができる。 OpenShiftが提供している運用ツール類を全て使用する場合は、 ユーザーのコンテナを実行する Worker Node とは別に、追加 の Worker Node が必要と考える。(Elastic Search 等は負荷 が高いため、専用ノードを用意する事を考える) Kubernetes は IDを管理 する仕組みをもっていな いため、管理ユーザー以 外のユーザーが使用する 場合は、LDAP等のID管 理サーバーが必要。 OpenShift のクラスターは必ずド メイン名が必要。 インターネットからアクセスでき るようにする場合は、インター ネット上のドメイン取得が必要。 Nodeを追加した時に、環境にIP アドレスを割り振る。 冗長化 ClusterへのNode追加時 にはロードバランサーの 設定の追加が必要 OpenShift の IPI (Infrastructure Provisioned Installation) で は、VIP (Virtual IP) を、OpenShift Cluster 側に持つ事で、ロー ドバランサー機能を Cluster 側に持つ構成もある。
42. Red Hat OpenShift Container Platform 補則：OpenShift 習得のために 42
43. OpenShift を自分で学ぶ (セルフ・ラーニング) (1) クラウドサービス (有料) クラウド・プロバイダーから提供されている Managed の OpenShift サービスです。 IBM RHOIC AWS ROSA Azure ARO (Azure Red Hat OpenShift) Red Hat OpenShift Dedicated (60日のトライアルあり) (2) オンラインの無料 SaaS サービス (Katakodaを使った学習サービス) (無料) セットアップされた環境で、ガイド付きの学習サービスを受ける事ができます。 ・OpenShift の基本的な使い方 Courses and scenarios authored by OpenShift | Katacoda ・O’REILY のページ。OpenShift の上でいろいろなアプリを作成してみるトレーニング OpenShift: Interactive Learning Portal (3) オンライン上のアプリ開発者向けサービス「Developer Sandbox for Red Hat OpenShift」(無料) 「Code Ready Workspace」 と言うブラウザから使用する SaaS開発環境と、セットアップ済みのオンラインのOpenShift 環境を 30日間提供しています。 (4) Code Ready Container (無料) – オンプレ (PC向き) テスト用にローカルのPCにインストールする事を目的とした、仮想マシンのシングルノードの OpenShift です。Kubernetes で言う minikube に相当します。 カテゴリーの記事一覧 赤帽エンジニアブログ (5) OKD (無料) – オンプレ / クラウド OpenShift の OSS版です。OpenShift のフル機能が使えます。 自分で構築して OpenShift / Kuberentes のインフラとしての構造を知りたい人向けです。AWS / Azure / GCPにも簡単に環境を作れます。 HWの要求仕様が高いので使用できるサーバー・リソースをたくさん持っている人向けです。 43
44. OpenShift を自分で学ぶ (セルフ・ラーニング) (6) 60日の評価版ライセンス (4)の Code Ready Container 60 日評価版 OpenShift の Software の評価版です。 AWS / Azure / GCP 等の上にインストールする場合は、クラウドの費用は別途必要です。 同じリンク先に (1) で紹介した Managed Service や、(4)の Code Ready Container へのリンクもあります。 (1)の Managed Service
45. Red Hat OpenShift Container Platform まとめ 45
46. まとめ 46 • OpenShift では、Kubernetes コアには含まれてないが、実際には必要な 3rd Party コンポーネントを、パッ ケージし、サポートと伴に提供しています。 • コンテナの開発、運用に必要なツール類を提供 ( CI/CDツール、Integrated Regstry、Monitoring / Logging / Service Mesh等) • OSレイヤー、コンテナ・ベースイメージ(UBI)、基本的なミドルウェアライブラリまで、一貫したサポートを提 供します。 • Kuberentes には存在しない、もしくはベータの機能であるような機能でも、拡張機能を提供する事で、エンタ プライズ環境でも使いやすくしています。 • ベンダー依存を廃する事で、パブリック・クラウドから、オンプレミスまで、殆どの環境で使用できます。将来 の環境変化に対する保険として、ハイブリットクラウドを目指した設計に最適な製品となっています。
47. linkedin.com/company/red -hat youtube.com/user/RedHat Videos facebook.com/redhatinc twitter.com/RedHat Red Hat is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. 47