Tweet
Tweet

Slide 1

Slide 1 text

OpenShiftクラスターの アップグレード自動化への挑戦！ Red Hat K.K. Solution Architect / Sales

Slide 2

Slide 2 text

Copyright © 2023 Red Hat K.K. All Rights Reserved. 2 自己紹介 北村 慎太郎 Red Hat - Specialist Solution Architect - OpenShiftを中心としたプリセールス 過去にSREチーム立ち上げ経験あり #Kubernetes #OpenShift #AWS #GCP #Terraform

Slide 3

Slide 3 text

なぜ OpenShiftアップグレードが 必要なのか？ 3

Slide 4

Slide 4 text

コンテナ導入に期待する価値 開発アジリティの向上 Agility トータルコストの削減 Optimize 安定したサービス維持 Steady コンテナではアプリケーション開 発者の判断で、リソースを調達で きるので、新規開発や変更が迅 速に行える。 自律的な運用により、障害が起 きても人の手を借りずにすぐに復 旧が行われ、安定的に動作する ように設計されている。 インフラリソースは抽象化されて おり、必要なリソースを定義する と、動的にアプリケーションに適 したリソースが払い出される。 開発・運用を支援する 多数の機能 豊富なセキュリティ機能と 迅速なパッチ提供 Red Hatのスペシャリストによ るサポート 4

Slide 5

Slide 5 text

5 クラスターアップグレードの必要性 新機能の追加 バグのFIX セキュリティ対策 サポート ● OpenShiftは日々開発が行われ、開発・運用の効率化 を促進するための新機能が追加されていく ● OpenShift導入の目的を継続的に達成するためには、 新機能をうまく活用していくことが必要 ● OpenShiftではKubernetesのリリースサイクルに従いなが らセキュリティパッチを提供する ● 利用者は定期的にセキュリティパッチを適用することで脆弱 性を突いた攻撃を防御する ● Kuberntes/OpenShiftはソフトウェアのため、バグが 混入している可能性がある ● バグの対応は基本的にパッチリリースを適用（アップグ レード）する形になる ● 性能向上や安定化もパッチリリースに含まれる ● OpenShiftはKubernetesのリリースサイクルに準拠した形 で新バージョンがリリースされる ● Kubernetesのサポート期間が1年間のため、OpenShiftもあ る程度その期間に縛られた形でサポート期間を設定されて いる コンテナ導入効果の最大化には、 OpenShiftの継続的なアップグレードが必要

Slide 6

Slide 6 text

OpenShift アップグレード戦略 6

Slide 7

Slide 7 text

OpenShiftのアップグレード Master Node Kubernetes API (etcd/api) ホストOS(CoreOS) クラスタ管理サービス (クラスタOperator) Worker Node ホストOS(CoreOS) Kubernetesコンポーネント (kubelet, CRI-O) Master Nodeのアップグレード Kubernetes API: etcd/apiなどのコアコンポーネント クラスタ管理サービス : PrometheusやCNIなどのCluster Operator ホストOS: CoreOSのライブアップグレード Worker Nodeのアップグレード Kubernetesコンポーネント: CNI, kubeletなどの管理対象コンポー ネント One-click Upgrade 運用者 OTAアップグレード対象外のコンポーネント ・ユーザーでインストールした Operator ・ユーザーがデプロイした Kubernetes Manifest ワンクリックでOpenShiftクラスタをアップグレードする「 Over-the-Air (OTA) Upgrade」機能を提供しており、コンポーネント ごとの管理が不要です。 7

Slide 8

Slide 8 text

8 アップグレード戦略 アプリへの影響 アプリのSLO/SLAは？ 人的コスト アップグレードに かけられる稼働は？ インフラコスト アップグレードに かけられるリソースは？ リスク アップグレード失敗時の 影響は？ 様々な要素をもとに最適なアップグレード方式を検討 ①In-placeアップグレード ②Blue/Greenアップグレード Cluster 01 OpenShift 4.9→4.10 Cluster 01 OpenShift 4.9→4.10 Load Balancer 1st upgrade Cluster 02 OpenShift 4.9→4.10 2nd upgrade アクセス制御 単一クラスターでアップグレードを実行 複数クラスターで順番にアップグレード アップグレード前に対象のクラスターをサービスアウト OpenShiftのアップグレードには、単一クラスターのみで実施する In-placeアップグレードと、複数クラスターを活用する Blue/Greenアップグレー ド戦略があります。アプリケーションの SLOやアップグレードに許容できるコストを鑑みて適切な戦略を採用します。

Slide 9

Slide 9 text

In-placeアップグレード In-place方式では、搭載しているワークロードの可用性を維持しながらアップグレードを完了する必要があります。 Blue/Green方式に比べてアプリへの影響が発生しやすいため、アプリケーションの構成やマニフェストの設定における考慮が必要です。 NodeA OCP 4.9→4.10 NodeB OCP4.9 NodeA OCP 4.10 NodeB OCP 4.9→4.10 Stateful Data Stateful Data In-placeアップグレード In-place Blue/Green 1ノード分のPodが起動 できる余剰が必要 クラスター内の別のノード からもアクセス可能な構成 を取っておく ノードの再起動に備え静的 データをクラスター外部に 切り出しておく 9

Slide 10

Slide 10 text

Blue/Greenアップグレード マルチクラスター構成を取り Blue/Greenアップグレードを実施することで、ノード停止を意識せずに安全にアップグレードを 実現できます。 各クラスターのアップグレードは OpenShiftのOTAアップグレードにて対応します。 In-place Blue/Green Load Balancer Cluster A Cluster B OpenShift 4.9 OpenShift 4.9 Service Out Load Balancer Cluster A Cluster B OpenShift 4.9 OpenShift 4.9→4.10 Upgrade Load Balancer Cluster A Cluster B OpenShift 4.9 OpenShift 4.10 ①サービスアウト ②バージョンアップ ③サービスイン Blue/Greenアップグレード Service Out User User User Stateful Data Stateful Data Stateful Data サービスアウトした後で アップグレードを実施 10

Slide 11

Slide 11 text

11 アップグレードに伴う事前検証 可能な限り 環境を合わせる Compute Resource OS Version (Source/Destination) Operator Workload (Deployment/Service) Cluster Resource (Namespace/ClusterRole) Infrastructure Resource クラスター構成 アップグレード戦略 （Rolling/BG/etc…） Compute Resource OS Version (Source/Destination) Operator Workload (Deployment/Service) Cluster Resource (Namespace/ClusterRole) Infrastructure Resource クラスター構成 アップグレード戦略 （Rolling/BG/etc…） Develop / Staging Production 採用するアップグレード手法に関わらず、アプリケーションが正常に動作することを事前に検証した上でアップグレードを実行します。アップグ レード前後の確認はできるだけ商用に近しい環境で実施することが推奨されます。 In-place Blue/Green

Slide 12

Slide 12 text

12 各アップグレード方式の比較 In-placeアップグレード Blue/Greenアップグレード インフラのコスト ◯ ・単一クラスターのため低コスト × ・複数クラスターが必要なため高コスト 作業コスト ◯? ・OTAアップグレード実行のみ（メンテナンスウィンドウを設け る ならアプリチームとの調整が必要） × ・2つのクラスターの準備、両クラスターへのアプリデプロイ、切り替 え作業などが発生 アプリSLAへの影響度 × ・メンテナンスウィンドウの設定やノード再起動によってアプリ のSLAに影響を及ぼす可能性が高い ◯ ・LBやDNSの切り替えでサービスアウトした上でアップグレードする ためアプリへの影響を最小化できる アップグレード失敗時の対処 × ・切り戻し不可 ・RHサポートと連携して失敗原因を取り除くが、解決するまで はサービス断が発生 ◯ ・正常なクラスターへ切り戻し後、失敗の原因調査が可能 アプリ設計への考慮 × ・Drainに備えてマニフェストの設計の考慮が必要（メンテナン スウィンドウが設けられるなら省力化が可能） ・ステートフルデータの外部データ管理が必要 △ ・ステートフルデータの外部データ管理が必要 インフラ設計への考慮 △ ・クラスター内からのノードから外部データアクセスが必要 × ・クラスター間からの外部データアクセスが必要 ・ユーザーアクセスの上段切り替え用の LBやDNSの設置が必要 採用方針 ・メンテナンスウィンドウが許容できる ・失敗時、トラブルシューティング中のサービス断を許容できる ・アップグレードに対するコストを最優先にしたい（多少のリスクを許 容する） ・商用環境以外のクラスター（開発・テスト環境など） ・コスト削減よりもアプリ停止のリスクの最小化を優先したい ・アップグレード失敗時の切り戻し方法を準備しておきたい ・複数クラスターからアクセスできるデータベースやオブジェクトストレージ を準備できる

Slide 13

Slide 13 text

13 👆 ここまで前段 ここから本番 👇

Slide 14

Slide 14 text

14 “アップグレードをしない”という選択 OpenShift自体をImmutableなインフラストラクチャと捉え、アップグレードを使わずに新バージョンでクラスターを作成後、アプリケーションを 移行するといった戦略も検討できます。 クラスター アップグレード （In-place） 運用者 新バージョン クラスター作成 アプリケーションデプ ロイ 旧バージョン クラスター削除 クラスター アップグレード （Blue） 通信切り替え クラスター アップグレード （Green） 通信切り替え

Slide 15

Slide 15 text

Blue/Greenアップグレードの派生系 Load Balancer Cluster A Cluster B OpenShift 4.9 OpenShift 4.9 Service Out Load Balancer Cluster A Cluster C OpenShift 4.9 OpenShift 4.10 Create Load Balancer ①サービスアウト ②クラスター作成 ③サービスイン クラスターをアップグレードするのではなく、新しいバージョンで新規作成し、切り替え後に旧クラスターを削除します。 Blue/Greenアップグレード(Recreate) User User User Stateful Data Stateful Data Stateful Data 新しいバージョンの クラスターを再作成 Cluster B OpenShift 4.9 Cluster A Cluster C OpenShift 4.9 OpenShift 4.10 Cluster B OpenShift 4.9 切り替え後問題なければ クラスターを削除 通常のB/Gと同様、ステート フルデータはクラスター外に 切り出しておく Destroy 15

Slide 16

Slide 16 text

16 【参考】クラスター再構築の必要性 ● OpenShift/Kubernetesクラスター自体の障害復旧に対しては 再構築が基本対応 となる ● 再構築したクラスターを障害前と同様の状態にする ために必要なものや作業内容を検討する 2.PVリストア 4.サービス切替 必要なもの ・クラスタ構成 (install-config.yaml) ・クラスター用マニフェスト 必要なもの ・PVのバックアップデータ 必要なもの ・アプリ用マニフェスト ・コンテナイメージ 作業ステップ ・以前のクラスタと同じ論理構成で OpenShiftクラスタを再構築する ・クラスター用マニフェストをデプロ イする (ResourceQuota/Operatorなど) 作業ステップ バックアップデータを用いてPV内 のデータリストアを行う 作業ステップ ・アプリ用マニフェストを再適用する 作業ステップ ロードバランサーなど、サービスの 提供に必要なOpenShift外の機器 ・コンポーネントの設定を必要に応 じて変更する App再配置 ・起動 1.クラスタ再構築 3.マニフェスト 再適用

Slide 17

Slide 17 text

17 【参考】ROSAのサービス定義例

Slide 18

Slide 18 text

18 GitOpsによるクラスターの早期構築 Gitリポジトリに置かれたコードを信頼する唯一の情報源 “Single Source of Truth” とみなし、コードとインフラを常に同じ状態に保つ運用のベス トプラクティスを GitOpsと呼びます。クラスターの構成や設定情報をコードで管理することで、クラスター構築を自動化し 高頻度のアップグレードに対応できるようになります。 Stateful Data IaCツール (Ansible/Terraform) K8s Cluster Manifset K8s Workload Manifset CI/CDツール (Tekton/ArgoCD) Application Code Deployment Service Configmap Namespace Role/ RoleBinding Quota Operator CustomResource User Network Security Monitoring IAM Batch Storage Compute OCP v4.9 Infra Code 破棄して新規に構築 開発者 運用者 CI/CDツール (Tekton/ArgoCD) Network Security Monitoring IAM Batch Storage Compute OCP v4.10 Git Repository Git Repository Git Repository Database Object Storage ‥‥ ‥‥ Deployment Service Configmap Namespace Role/ RoleBinding Quota Operator CustomResource User ‥‥ ‥‥

Slide 19

Slide 19 text

19 アップグレードの自動化（例） OpenShift Tekton Pipelines Load Balancer Cluster A Cluster B OpenShift 4.9 OpenShift 4.10 Create User Cluster A Cluster B OpenShift 4.9 OpenShift 4.10 User Load Balancer Destroy Create Cluster App Deploy System Test Modify Routing Health Check Destroy Cluster Cluster Setting Operator Infra Code K8s Cluster Manifset Push K8s Workload Manifset

Slide 20

Slide 20 text

20 アップグレードの自動化（例） OpenShift Tekton Pipelines Load Balancer Cluster A Cluster B OpenShift 4.9 OpenShift 4.10 Create User Cluster A Cluster B OpenShift 4.9 OpenShift 4.10 User Load Balancer Destroy Create Cluster App Deploy System Test Modify Routing Health Check Destroy Cluster Cluster Setting Operator Infra Code K8s Cluster Manifset Push K8s Workload Manifset そんな簡単に言うけどで きるの・・・？😥

Slide 21

Slide 21 text

21 アップグレードの自動化（例） OpenShift Tekton Pipelines Load Balancer Cluster A Cluster B OpenShift 4.9 OpenShift 4.10 Create User Cluster A Cluster B OpenShift 4.9 OpenShift 4.10 User Load Balancer Destroy Create Cluster App Deploy System Test Modify Routing Health Check Destroy Cluster Cluster Setting Operator Infra Code K8s Cluster Manifset Push K8s Workload Manifset やってみよう👍

Slide 22

Slide 22 text

クラスターアップグレードデモ Blue/Green アップグレードデモ 22

Slide 23

Slide 23 text

us-east-2 us-east-1 DB-VPC ROSA-1-VPC 23 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering ROSA-1 ROSA-2-VPC ROSA-2 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config sample-blog openshift- gitops cluster-admin Tekton Pipeline Custom Task image app- frontend app- backend pull-secret app- frontend app- backend K8s Workload Manifset Infra Code K8s Cluster Manifest

Slide 24

Slide 24 text

us-east-2 us-east-1 DB-VPC ROSA-1-VPC 24 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering ROSA-1 ROSA-2-VPC ROSA-2 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config sample-blog openshift- gitops cluster-admin Tekton Pipeline Custom Task image app- frontend app- backend pull-secret app- frontend app- backend K8s Workload Manifset Infra Code K8s Cluster Manifest Blue-App (ROSA) Green-App (ROSA) 自動化環境 (OpenShift on AWS)

Slide 25

Slide 25 text

us-east-1 DB-VPC ROSA-1-VPC 25 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering Infra Code K8s Cluster Manifest ROSA-1 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config Tekton Pipeline Custom Task image app- frontend app- backend git-clone ・パイプライン全般で使用する各種マニ フェストやterraformコードが格納され た リポジトリをCloneする

Slide 26

Slide 26 text

us-east-1 DB-VPC us-east-2 ROSA-1-VPC 26 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering Infra Code K8s Cluster Manifest ROSA-1 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config Tekton Pipeline Custom Task image app- frontend app- backend rosa-init ・ROSAクラスターを構築する前の準備 用コマンドを実行する 　・rosa login 　・rosa init 　・rosa create account-roles

Slide 27

Slide 27 text

us-east-2 us-east-1 DB-VPC ROSA-1-VPC 27 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering Infra Code K8s Cluster Manifest ROSA-1 ROSA-2-VPC ROSA-2 rosa- init create-c luster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config Tekton Pipeline Custom Task image app- frontend app- backend create-cluster ・ROSAクラスターの構築コマンドを実 行する 　・rosa create cluster

Slide 28

Slide 28 text

us-east-2 us-east-1 DB-VPC ROSA-1-VPC 28 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering Infra Code K8s Cluster Manifest ROSA-1 ROSA-2-VPC ROSA-2 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config Tekton Pipeline Custom Task image app- frontend app- backend check-create ・ROSAクラスターのステータスが Readyになるまでチェックする 　・rosa list cluster

Slide 29

Slide 29 text

us-east-2 us-east-1 DB-VPC ROSA-1-VPC 29 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering Infra Code K8s Cluster Manifest ROSA-1 ROSA-2-VPC ROSA-2 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config Tekton Pipeline Custom Task image app- frontend app- backend prepare-vpc-peering create-vpc-peering ・ROSAクラスターのVPCとDBのVPC の間にVPCピアリングを張る ・prepareではawsコマンドを使って VPC のIDを取得し、terraformのファイルに 書き込む ・createではterraformでVPCピアリン グの設定を行う

Slide 30

Slide 30 text

us-east-2 us-east-1 DB-VPC ROSA-1-VPC 30 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering Infra Code K8s Cluster Manifest ROSA-1 ROSA-2-VPC ROSA-2 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config cluster-admin Tekton Pipeline Custom Task image app- frontend app- backend create-cluster-admin ・ROSAクラスター内にCluster-admin ロールのユーザーを作成する 　・rosa create admin

Slide 31

Slide 31 text

us-east-2 us-east-1 DB-VPC ROSA-1-VPC 31 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering Infra Code K8s Cluster Manifest ROSA-1 ROSA-2-VPC ROSA-2 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config cluster-admin Tekton Pipeline Custom Task image app- frontend app- backend decrypt-secret ・AWS KMSであらかじめencryptしてい たsecretファイルをdecryptする ・ここでは後ほどデプロイする pull-secret情報をdecryptしている

Slide 32

Slide 32 text

us-east-2 us-east-1 DB-VPC ROSA-1-VPC 32 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering Infra Code K8s Cluster Manifest ROSA-1 ROSA-2-VPC ROSA-2 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config sample-blog cluster-admin Tekton Pipeline Custom Task image app- frontend app- backend pull-secret app- frontend app- backend prepare-deploy ・アプリをデプロイする前の準備を行う 　・アプリNamespaceを作成 　・decryptしたpull-secretをデプロイ 　・pull-secret情報をもとに管理用クラ スターからイメージをインポート 　　・oc import-image

Slide 33

Slide 33 text

us-east-2 us-east-1 DB-VPC ROSA-1-VPC 33 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering Infra Code K8s Cluster Manifest ROSA-1 ROSA-2-VPC ROSA-2 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config sample-blog openshift- gitops cluster-admin Tekton Pipeline Custom Task image app- frontend app- backend pull-secret app- frontend app- backend argocd-install ・openshift-gitops Operatorをインス トールする ・Operatorのインストール状況をチェッ クし、完了したらアプリデプロイ用の ArgoCDのカスタムリソースをデプロイ する

Slide 34

Slide 34 text

us-east-2 us-east-1 DB-VPC ROSA-1-VPC 34 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering Infra Code K8s Cluster Manifest ROSA-1 ROSA-2-VPC ROSA-2 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config sample-blog openshift- gitops cluster-admin Tekton Pipeline Custom Task image app- frontend app- backend pull-secret app- frontend app- backend argocd-access-configuration ・argoCDへのアクセスに必要な情報 （URL/adminパスワード）を取得する

Slide 35

Slide 35 text

us-east-2 us-east-1 DB-VPC ROSA-1-VPC 35 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering Infra Code K8s Cluster Manifest ROSA-1 ROSA-2-VPC ROSA-2 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config sample-blog openshift- gitops cluster-admin Tekton Pipeline Custom Task image app- frontend app- backend pull-secret app- frontend app- backend K8s Workload Manifset sync-application ・argoCDに対してsyncを実行してアプ リをデプロイする

Slide 36

Slide 36 text

us-east-2 us-east-1 DB-VPC ROSA-1-VPC 36 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering Infra Code K8s Cluster Manifest ROSA-1 ROSA-2-VPC ROSA-2 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config sample-blog openshift- gitops cluster-admin Tekton Pipeline Custom Task image app- frontend app- backend pull-secret app- frontend app- backend K8s Workload Manifset change-route53-record ・アプリのアクセス URLをDNSレコード の設定変更で切り替える

Slide 37

Slide 37 text

us-east-2 us-east-1 DB-VPC ROSA-1-VPC 37 B/G アップグレードデモ OpenShift git- clone prepare- vpc-peering Infra Code K8s Cluster Manifest ROSA-1 ROSA-2-VPC ROSA-2 rosa- init create- cluster create- cluster-admin decrypt- secret argocd- install prepare- deploy sync- application change- route53-record create- vpc-peering check- cluster argocd- access-config sample-blog openshift- gitops cluster-admin Tekton Pipeline Custom Task image app- frontend app- backend pull-secret app- frontend app- backend K8s Workload Manifset 完了！

Slide 38

Slide 38 text

38 今日のデモで伝えたかったこと これがベストプラクティス！ （1週間程度で）アップグレードはここまで自動化できる！！ ちゃんと動いたよね ...？ 自動化を恐れずに積極的に取り組んでいこう！！ まだまだ検討要素はたくさんある ・今回はROSAだったのでクラスターインストールが簡単だった。UPIインストールの場合はAnsibleやTerraformを使ってサーバの構築から自動化が必要 ・最低限のリソースのみをデプロイしていたが、Operatorやユーザー追加、RBACと事前に設定するものが増えるとその分自動化作業も増える ・Secret管理が難しい（事前にSealedSecretで暗号化したSecretをGitにアップすることができない） ・単一アプリのみが載るクラスターを前提としていた。複数アプリが載っているともっと考慮事項が増える（これは手動でも同じ） ・今回はアプリデプロイ後の正常性は手動で簡単に行ったが、本来はアプリのCIテストを間で実行する方が良い ・モニタリングツールの外型監視などを使い、サービスへの影響が最小限に止まっているかを確認する ・etc..

Slide 39

Slide 39 text

39 【参考】ROSAクラスターのアップグレード戦略 高信頼性が求められるROSAクラスターでは、New Cluster構築による対応を推奨 ＜ROSA特有のメリット＞ ・サブスクリプションが時間単位での従量課金のため、クラスターの柔軟な増減に対応可能 ・Managedサービスのためデプロイ時の設定が限られており、クラスター構築の自動化が容易 ＜課題解決＞ ・アップグレードパスの考慮が不要 ・Operatorのバージョンを（パッチバージョンを含めて）指定することができる ＜その他のメリット＞ ・クラスターのステートに依存したエラーを回避できる 　　・動作検証やエラー調査などの際、バージョンアップ前のクラスターの状態を考慮する必要がない

Slide 40

Slide 40 text

まとめ 40

Slide 41

Slide 41 text

41 変更に強い基盤でコンテナ導入効果の最大化を目指す アップグレードに必要な作業が多くてライフサイクルに追 従できない‥‥ IaCやCI/CD、自動テストなどを積極的に活用 してアップ グレードの作業コストを削減する アプリケーションが停止しないための対策 を実施する Kubernetes/OpenShiftの導入価値とアップグレードの 必要性を正しく理解する 開発チームとのメンテナンスウィンドウの調整が難航す る‥‥ 従来のインフラのように塩漬け運用できないか‥？ 従来の運用の考え方を適用すると‥‥ コンテナ環境に合わせた運用の変革 アプリケーションだけでなく それを支えるプラットフォームも ”変更に強い”状態を目指す OpenShiftアップグレードとの関わり方

Slide 42

Slide 42 text

linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Thank you 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.

Slide 43

Slide 43 text

43 デモで使ったコードはこちら↓ https://github.com/skitamura7446/openshift-upgrade-automation