OpenShift学習モメ

OpenShift Web Console

目標

OpenShift Web コンソールを使用して効果的に管理および設定する方法について理解する。

OpenShift Web コンソールへのアクセス

• ログイン情報を取得

crc console --credentials

• Webコンソールを開く

crc console

• Webコンソールへkubeadminでログイン
  

概要

• 画面左上隅にあるスイッチャーで、管理者と開発者の視点を切り替えることができる。
• 画面左側のナビゲーションメニューで、様々なセクションや機能にアクセスできる。

管理者画面

• クラスタ、インベントリ、容量、CPU・メモリ使用率など様々な情報にアクセスできる。
• ユーザーアクセスの管理、クラスターの更新、カスタムリソース定義など。

開発者画面

• 開発者向けに調整されているワークフローを提供
• プロジェクト、ビルド管理など
• プロジェクトをGUIで作成し、該当プロジェクトに関する設定を確認することができた。
• 検索メニューからプロジェクトの特定リソースについて確認することができた。

OpenShift CLI

目標

コマンドラインインターフェース（CLI）、特にOCコマンドを効果的に使用する方法を理解する。

• ログインコマンド

oc login -u kubeadmin -p <password> <URL>

• プロジェクト作成

oc new-project <projectname>

• プロジェクトのステータスの概要取得

oc status

• プロジェクトのステータスの概要取得（プロジェクト指定）

oc status -n <projectname>

• プロジェクトのステータスの概要取得（全プロジェクト指定（namespace））

oc status -A

→CrashLoopBackOffエラーが出力。やっぱり、相当いいパソコンじゃないとCRC環境はうまく動作しないかも。。。

• アプリケーションデプロイ（ソースコードの場所を指定して新しいアプリケーションを作成可）

oc new-app --name=first-app --image=openshift/hello-openshift

• プロジェクトで実行されているポッドに関する情報を取得。

oc get pods -o wide

• 特定のポッドまたはデプロイメントのログを表示。

oc logs deployment/<app>

• クラスター内で利用可能なAPIリソースを表示。

oc api-resources

• OCコマンドについてカテゴリ別にグループ化された使用可能なコマンドの包括的なリストを表示。

oc help

• 特定のコマンドに関する詳細情報が必要な場合。（例：createコマンドの場合）

oc create --help

• 高度なクラスター管理タスクで使用可能なタスクのサブコマンドを確認する。

oc adm --help

→とりわけ重要なコマンドは覚えておき、必要に応じてhelpコマンドを利用して正しいコマンドを利用できるようになることが大切。

OpenShift リソースのクエリ、フォーマット、フィルター

目標

kubernetesの属性のクエリ、フォーマット、フィルタリングについて理解する。

• Podのステータスを確認（一覧形式で）

oc get pods

• 特定のPodの詳細情報を確認（YAMLorJSON）

oc get pod <podname> -o yaml

oc get pod <podname> -o json

• 特定のPodの詳細情報を確認（describe）

oc describe pod <podname>

• 特定のPodの詳細情報から任意のリソース属性を確認（describe）

oc describe pod <podname> | grep IP

• Podの情報をクエリを利用して出力

oc get pods -o custom-columns=NAME:.metadata.name,RSRC:metadata.labels

• 特定のラベルを持つPodのみをリストで出力

oc get pods -l deployment=<labelname>

• 特定のフィールドを指定して出力（実行中のPodを出力）

oc get pods --field-selector=status.phase=Running 

→リソースのクエリ、フォーマット、フィルターを指定することで、必要な情報を正確に指定し出力することができる。モニタリングやトラブルシューティングに役立つ。

OpenShift リソースのインポートとエクスポートと構成

目標

kubernetesリソースのインポート、エクスポート、構成について理解する。

インポート

• 指定されたディレクトリに定義されているリソース構成を適用（更新or適用）

oc apply -f ./<directoryname>

• 指定されたファイル（yaml）に定義されているリソース構成を適用（更新or適用）

oc apply -f ./<directoryname>/<filename>

エクスポート

• 指定されたデプロイメント定義をyaml形式で出力

oc get deployment <deployname> -o yaml > <filename>

• secretのリストを標準出力

oc get secrets

• 特定のsecretを情報を標準出力

oc extract secret/<secretname>

• 特定のsecretを情報をファイルへ出力

oc extract secret/<secretname> --to=./<filename>

• エクスポートしたyamlファイルの更新

nano <filename>

→viでもおけ

• 更新したyamlファイルを適用

oc apply -f <filename>

→競合エラーがでたので、oc apply -f <filename> --forceで実行したらうまくいった

宣言型と命令型

命令型

• oc create、oc delete、oc replace、oc editなど
• 命令型のコマンドは、特別の状況では必要であり便利だが、通常はより詳細なコマンド指定が要求される
• 監視と手動管理が必要となるため、エラーや不一致が発生する可能性が高くなる

宣言型

• oc apply
• 目標状態を宣言（構成ファイル定義）することで、OpenShiftがその状態を達成する方法を自動で判断し、リソースの作成や更新をしてくれる。

→基本的にoc apply（宣言型）の使用をしたほうがいい。命令型は、緊急時や簡単な動作確認の際に使用するにとどめたほうが安全。

コンテナイメージを見つけて調べる

目標

OpenShift管理者として、OpenShift上で実行されているコンテナイメージを検索して調べる方法を理解する。

• コンテナイメージストリームをリスト表示

oc get imagestream -n openshift

• 特定のコンテナイメージストリームの詳細情報を表示

oc describe is <imagestreamname> -n openshift

• 特定のコンテナイメージの詳細情報を表示

oc describe image <image>

• コンテナイメージのダウンロード

oc image extract

＜イメージストリームとは？＞

• OpenShift のリソースの 1 つ。
• コンテナイメージそのものは含まず、コンテナイメージを参照を行うためのリソース。
• コンテナイメージの参照を抽象化し、ImageStream とタグによって利用可能なイメージを管理。

👇を読み込んでもう少し、コンテナ、イメージ、イメージストリームの違いを理解する。
https://docs.redhat.com/ja/documentation/openshift_container_platform/4.2/html/images/understanding-images#understanding-images

プロジェクトの作成と削除

目標

OpenShift管理者として、プロジェクトの概念と作成、削除方法を理解する。

プロジェクトの概念

• プロジェクトは、リソースを整理および分離するためのOpenShiftの基本概念。
• 他のユーザと作業空間を分けたり、作成されるイメージ名の一部になったりと、名前空間としての役割を持つ。
• 他にもユーザが使用可能なメモリやCPUなどのリソースをProject単位で制限したり、他のユーザに自分のProjectを見せたり編集させたりする権利を明示的に与える等、様々な役割がある。
  👇以下参考サイト
  https://thinkit.co.jp/article/15696

プロジェクトの作成と削除（CLI）

• developerユーザーでocログイン

oc login -u developer https://api.crc.testing:6443

Logged into "https://api.crc.testing:6443" as "developer" using existing credentials.

You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

• プロジェクト作成（例：my-demon-projectを作成）

oc new-project my-demo-project --description='My demonstration project' --display-name='Demo Project'

Now using project "my-demo-project" on server "https://api.crc.testing:6443".

You can add applications to this project with the 'new-app' command. For example, try:

    oc new-app rails-postgresql-example

to build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application:

    kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.43 -- /agnhost serve-hostname

• 現在のプロジェクトを表示

oc project

Using project "my-demo-project" on server "https://api.crc.testing:6443".

• アプリケーションの作成

oc new-app --name=my-app --image=openshift/hello-openshift

--> Found container image 7af3297 (6 years old) from Docker Hub for "openshift/hello-openshift"

    * An image stream tag will be created as "my-app:latest" that will track this image

--> Creating resources ...
    imagestream.image.openshift.io "my-app" created
    deployment.apps "my-app" created
    service "my-app" created
--> Success
    Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
     'oc expose service/my-app' 
    Run 'oc status' to view your app.

• Podのステータスを確認

oc get pods

• プロジェクト内の全リソースを確認

oc get all

• プロジェクトの詳細情報を確認

oc describe project my-demo-project

• プロジェクトの削除

oc delete project my-demo-project

プロジェクトの作成と削除（Webコンソール）

作成

• 左上隅の「追加」をクリックして、「プロジェクトの作成」をクリックする。
  

• 名前など入力し「作成」をクリックする。
  

削除

• 左の「プロジェクト」の右上の「アクション」タブで、「プロジェクトの削除」をクリックする。
  

• 削除したいプロジェクト名を入力し、「削除」をクリックする。
  

リソースとクラスターのステータスを調査する

目標

OpenShift管理者として、リソースとクラスターのステータスを調査する方法を理解する。

• 現在のプロジェクトのデプロイメントを調べる

oc get deployments

• 指定したプロジェクトのデプロイメントを調べる

oc get deployments -n <namespace>

• クラスター内のすべてのプロジェクトのPodを調べる

oc get pods --all-namespaces

• クラスターの状態（概要）を調べる

oc status

• クラスターのノードに関する情報を調べる

oc get nodes

• クラスターの各コントロールプレーンの状態を調べる

oc get componentstatuses

• Podのリソース使用状況を調べる

oc adm top nodes

oc adm top nodes --sort-by=cpu

oc adm top pods

oc adm top pods --namespace=my-namespace

oc adm top pods -l app=app-name

Webコンソールを用いたリソース使用状況を調べる

管理者権限でログインし、「ホーム」→「概要」の画面を開くと、6つのセクションがある。それぞれ、以下用途で活用し、リソース使用状況を確認する。

詳細

• クラスターのステータスと履歴のクイックリファレンスガイド
• クラスターID、インフラストラクチャープロバイダーなどの情報が含まれている

クラスターイベントリー

• ノードの数、ポッドの総数、ストレージクラス、永続ストレージ、クラスター内のボリューム要求などが表示される
• クラスターが動作している規模を評価するのに役出つ

ステータス

• さまざまなコンポーネントの動作状態を表示する
• クラスターのコントロールプレーンとオペレーターに関するステータス情報など
• 問題が発生しているコンポーネントや注意が必要なコンポーネントを特定するのに役立つ

クラスターの使用率

• さまざまなリソースの使用状況を表示する
• 傾向の特定、容量の計画、トラブルシューティングに役立つ

アクティビティー

• クラスターの動作パネルに関する最新情報を入手できる
• 最新のアクティビティやイベントのフィードを提供し、内部で何が起こっているかダイナミックに把握できる

https://qiita.com/Y-Shikase/items/dc05259efda697b91f50

ログ

目標

OpenShift管理者として、ログを効果的に表示する方法を理解する。

• ビルド構成の最新ログを表示

oc logs -f bc/<build-config-name>

• デプロイメントの最新ログを表示

oc logs -f deployment/<deployment-name>

• 特定バージョンのデプロイメントの最新ログを表示

oc logs -f deployment/<deployment-name> -version=<version-number>

• 特定バージョンのビルド構成の最新ログを表示

oc logs -f bc/<build-config-name> -version=<version-number>

• 特定Podの最新ログを表示

oc logs -f pod/<pod-name>

• ログの最後の数行だけを表示したい場合は、末尾にtailをつける

oc logs -f pod/<pod-name> --tail=10

• 特定ノードのログを表示

oc adm node-logs <node-name>

oc adm node-logs --role master

oc adm node-logs --role master -u kubelet

• 特定のPodの詳細情報を確認（describe）

oc describe pod <podname>

Webコンソールからの確認方法

• プロジェクト→インベントリー→Podをクリック。
• 確認したいPod名をクリックし、ログタグを閲覧するとログを参照できる。
• ダウンロードも可能なため、エビデンスも残しやすい。かつ、複数Podがある場合、Pod間の行き来が楽！
  

クラスター全体の健全性

目標

OpenShift管理者として、クラスター全体の健全性を確認する方法を理解する。

etcdの監視

oc get pods -n openshift-etcd

oc -n openshift-etcd rsh etcd-crc

etcdctl endpoint health

oc logs -n openshift-etcd etcd-crc

Operatorの監視

oc get clusteroperators

バージョンの確認

oc version

一般的な問題のトラブルシューティング

目標

OpenShift管理者として、一般的なトラブルシューティングのシナリオと対応方法を理解する。

コンテナの起動失敗/クラッシュ

主な原因

• アプリケーションコードの設定ミス
• 依存関係の欠落
• リソースの制約

調査方法

• コンテナログの確認

oc logs

oc describe

• リソースの確認

oc adm top

Podのステータス異常（Pendingなど）

主な原因

• 設定ミス
• リソースの不足

調査方法

• Podのイベント確認

oc describe

oc get events --field-selector

• Podの強制削除（スタック時など）

oc delete

クラスター（etcdの問題）

主な原因

• 処理遅延
• ディスクI/O
• ネットワーク接続エラー

調査方法

• etcd CTL

クラスター（ネットワークの問題）

主な原因

• ネットワークポリシーの誤り
• ファイアウォールルールの誤り
• ネットワークプラグインの誤り

調査方法

• Podネットワークの詳細とイベントを確認

oc describe

• Podへのping、traceroute、telnetなど

oc exec my-pod -- ping annther-pod

→大事なのは、全体構成をしっかり把握し、問題を特定し、どこを見るべきかを知ること。
→練習も大事だが、実際のトラブルシューティングの経験がより重要。

製品ドキュメントについて

目標

OpenShift管理者として、製品ドキュメントの活用方法を理解する。

以下OpenShiftの製品ドキュメントを読めば、基本的な内容からベストプラクティス、トラブルシューティングなどまでカバーできる。あとは、oc helpで必要に応じてコマンドの利用法を調べられればおけ。

https://docs.openshift.com/
https://docs.redhat.com/ja/documentation/openshift_container_platform/4.16#Develop

HTPasswd ID プロバイダーの構成について

目標

OpenShift管理者として、クラスターへのユーザーアクセス管理について理解する。

• パスワードファイルの作成

htpasswd -c -B -b htpasswd alice redhat123

• パスワードファイルにユーザー追加

htpasswd -B -b htpasswd bob redhat123

htpasswd -B -b htpasswd charlie redhat123

htpasswd -B -b htpasswd ted redhat123

• クラスターの設定（Webコンソール）
  管理者権限でWebコンソールへログインし、「管理」→「クラスター管理」→「設定」タブへ進む
  「OAuth」をクリックし、「アイデンティティープロバイダー」で「追加」タブからhttpdpasswdを選択し、作成したファイルを選択し追加。
  

クラスターの設定（CLI）

• シークレットの作成

oc create secret generic my-htpass-secret --from-file=htpasswd=htpasswd -n openshift-config

• OAuthのエクスポート

oc get oauth cluster -o yaml > oauth.yaml

• OAuthの情報を確認

oc explain oauth.spec

oc explain oauth.spec.identityProviders

• OAuthの構成を修正(シークレット名を修正)

vi oauth.yaml

• yamlをreplace

oc replace -f oauth.yaml

• Pod（openshift-authentication）の起動を確認

oc get pods -n openshift-authentication

htpasswd-g2qb5

HTPasswd IDの削除方法について

目標

OpenShift管理者として、HTPasswd IDの削除方法について理解する。

概要

• パスワードファイルからユーザーを削除し、secretを作り直し、replaceしなおす
• その後、クラスターのユーザー一覧からdeleteコマンドを使って、ユーザーを削除する

グループの作成方法と管理方法について

目標

OpenShift管理者として、グループの作成方法と管理方法について理解する。

• グループの作成とユーザーの作成

oc adm groups new testers alice bob charlie

• グループへ表示ロールの割り当てをする

oc adm policy add-role-to-group view testers -n manage-groups

• グループから特定ユーザーの削除

oc adm groups remove-users view testers alice

ユーザーおよびグループの権限の変更

目標

OpenShift管理者として、ユーザーとグループのアクセス許可を変更する方法について理解する。

・クラスター全体に適用されるRBACクラスターとローカルの2つのレベルのRABCクラスターがある。
・ロールバイディングというものが必要。

• グループの作成とユーザーの作成

oc adm groups new testers alice bob charlie

プロジェクトのリソース制限設定（リソースクォータ）

目標

OpenShift管理者として、プロジェクトのリソース制限設定（リソースクォータ）方法について理解する。

クラスターのリソース制限設定（リソースクォータ）

目標

OpenShift管理者として、クラスターのリソース制限設定（リソースクォータ）方法について理解する。

・複数のプロジェクトにまたがるリソース使用量の管理ができる。
→特定のグループやユーザーにも。

・テスト用のプロジェクトを2つ作成

oc new-project project-1

oc label namespace project-1 enviroment=production

oc new-project project-2

oc label namespace project-2 enviroment=production

・リソースクォータの作成

oc create clusterresourcequota production-quota --project-label-selector=enviroment=production --hard=cpu=10 --hard=memory=20Gi

・リソースクォータの表示

oc describe appliedclusterresourcequota -n project-1

→注釈とラベルを活用することで、複数のプロジェクにまたがるリソースクォータを適用できる。

プロジェクト制限範囲の構成

目標

OpenShift管理者として、プロジェクトの制限範囲と、それがプロジェクト内のリソース消費の管理にどのように役立つか理解する。

→yamlで事前に定義したリソース制限範囲を作ることによって、リソースの独占を防止し、公平なリソース割り当てを促進することができる。

・テスト用のプロジェクトを作成

oc new-project limit-range-demo

・マニュフェストファイルの用意

more limitrange.yaml

・マニュフェストファイルの適用（制限範囲の作成）

oc create -f limitrange.yaml

・適用した制限範囲の確認

oc get limits

・制限範囲を超えたPodを作成し、作成が失敗することの確認

oc create -f limitrange-test.yaml

・制限範囲に収まるようにyamlを再定義して、今度はPodが作れることの確認。

oc create -f limitrange-test.yaml

プロジェクトテンプレートの構成

目標

OpenShift管理者として、プロジェクトテンプレート構成について理解する。

・テンプレートを作成すれば、1つ1つのプロジェクトに対するリソース制限の設定作業を削減し、一貫性を保つことができる。

・テンプレートの作成

oc adm create-bootstrap-project-template -o yaml > template.yaml

vi template.yaml

・Namespaceにプロジェクトテンプレートを作成

oc create -f template.yaml -n openshift-config

・クラスターにもテンプレートを適用

oc edit projects.config.openshift.io/cluster

・OpenShfitAPIサーバPodの再起動を監視

oc get pod -n openshift-apiserver -w

・新規プロジェクトを作成してテスト

oc new-project test-project

oc get guota

oc describe limitrange

リソースマニフェストからアプリケーションをデプロイする

目標

OpenShift管理者として、リソースマニュフェストを使用してアプリケーションをデプロイする方法ついて理解する。

・リソースマニュフェストの構造

• apiVersion
• kind
• metadata
• spec

・リソースマニュフェスト作成手法

• webコンソールのyamlをコピーして作成
• --dry-runコマンドの利用

・開発者権限でログイン

oc login -u developer -p developer https://api.crc.testing:6443

・デプロイメントマニュフェストを作成

oc create deployment my-deployment -o yaml --image=bitnami/nginx --save-config --dry-run=client > my-deployment.yaml

・デプロイメントマニュフェストの中身を確認

cat my-deployment.yaml

・プロジェクトの作成

oc new-project manifests

・デプロイメントマニュフェストに基づいた、デプロイメントの作成

oc create -f my-deployment.yaml

・デプロイメントのステータス確認

oc get deployments

・デプロイメントマニュフェストの内容を変更してみる（レプリカ数を1から5に変更）。

vi my-deployment.yaml

oc apply -f my-deployment.yaml

※oc applyをするとキューブ（ctl.kubernetes.io）に保存されるらしいが、何者か？？

・デプロイメントマニュフェストの変更をテストする（実際には適用せず、クラスター内で実行）。

oc apply -f my-deployment.yaml --dry-run=server

・デプロイメントマニュフェストの変更をテストする（実際には適用せず、クライアント側として実行）。

oc apply -f my-deployment.yaml --dry-run=client

※ドライランオプションがクライアントに設定されている場合、サーバーに送信されるオブジェクトが出力される。
・デプロイメントリソースのyamlコードを取得

oc apply -f my-deployment.yaml --dry-run=client -o yaml

・デプロイメントリソースがスキーマに対して有効なのか確認

oc apply -f my-deployment.yaml --dry-run=server --validate=true

・デプロイメントリソースとデプロイメントマニュフェストの差分を表示

oc diff -f my-deployment.yaml

・Podの再起動

oc rollout restart deployment my-deployment

・デプロイメントリソースの削除

oc delete -f my-deployment.yaml

→リソースマニュフェストの構造から、リソースマニュフェストを効率的に作成するための実践的なやり方を学習できてよかった。

イメージ、OpenShift テンプレート、Helm チャートからアプリケーションをデプロイする

目標

OpenShift管理者として、イメージ、OpenShift テンプレート、Helm チャートからアプリケーションをデプロイする方法ついて理解する。

▪️コンテナイメージを使う方法
・新しいプロジェクトを作成

oc new-project deployapps

・アプリケーションのデプロイ（ApacheHTTPサーバアプリケーション）

oc new-app bitnami/apache

・アプリケーションのデプロイ（カスタム環境変数を使用してApacheHTTPサーバをデプロイ）

oc new-app --image=bitnami/apache --name=httpd2 --env=HTTPD_PORT=8080

→「bitnami/apache」のようなイメージ名は、oc get imagesで探せば出てくるもんなのか？

▪️テンプレートを使う方法
・テンプレートの検索

oc get templates -n openshift

・テンプレートの詳細情報を確認

oc describe template httpd-example -n openshift

・テンプレートのマニュフェストをファイル出力し確認

oc get template httpd-example -n openshift -o yaml > httpd-example-template.yaml

※テンプレートを使う場合は、こんな感じでローカルに出力し、カスタマイズして利用するのがベストプラクティス
・テンプレートのマニュフェストをカスタマイズして出力andデプロイ

oc process httpd-example -n openshift NAME=frontend -l app=web -o yaml > httpd-example-resources.yaml | oc apply -f -

・リソースが作成されたことの確認

oc get all

・特定のテンプレートのパラメータを表示

oc process --parameters -n openshift httpd-example

・テンプレートをプロジェクトのテンプレートライブラリにアップロードする

vi httpd-example-template.yaml

oc create -f httpd-example-template.yaml

・現状のプロジェクトに、テンプレートが登録されていることを確認

oc get templates

・登録したテンプレートでアプリケーションをデプロイできるか確認

oc new-app --template=httpd-example

▪️Helm チャートを使う方法
・新しいプロジェクトの作成

oc new-project helmdemo

・Helmチャートリポジトリの追加

helm repo add bitnami https://charts.bitnami.com/bitnami

・Wordpressのインストール

helm install wordpress-app bitnami/wordpress

・インストールされたかの確認

helm list

・helmリポジトリの更新

helm repo update

・Wordpressのインストール（ユーザー名とパスワードを指定してデプロイ）

helm install my-wordpress-app bitnami/wordpress --set wordpressUsername=admin --set wordpressPassword=secret

※Helmチャートの仕組みをもう少し理解する。特に利点。

1 回限りのタスクのジョブをデプロイする

目標

OpenShift管理者として、1 回限りのタスクのジョブをデプロイする方法ついて理解する。

▪️OpenShiftにおけるJOBの概念
→データ処理やバッチ計算、データベースの移行、バックアップ、１回限りのメンテナンスタスク。

▪️JOBの作成とデプロイ
・開発者権限でログイン

oc login -u developer -p developer https://api.crc.testing:6443

・JOBの作成

oc create job one-time-tasks --dry-run=client -o yaml --image=binami/apache -- ls

oc create job one-time-tasks --dry-run=client -o yaml --image=binami/apache -- ls > my-job.yaml

oc create -f my-job.yaml

▪️JOBのモニタリングと監視
・JOBの状態確認

oc get jobs

oc get pods

oc logs <podname>

▪️JOBの並行処理と完了
・JOBのマニュフェストファイルの修正（並行処理するPod数、Podが正常終了すると完了する、バックオフ定義を追加）

vi my-job.yaml

▪️JOBの失敗とクリーンアップの処理

oc delete job one-time-tasks

アプリケーションのデプロイメントを管理する

目標

OpenShift管理者として、アプリケーションのデプロイメントを管理する方法ついて理解する。

・OpenShiftのライフサイクルを効果的に管理する方法を理解することが重要だお
・アプリケーションのデプロイメント（更新のロールアウト、デプロイメントのスケーリング、ロールバックの処理など）。
・ロールアウト
→アプリケーションの更新をシームレスにロールアウトし、要件に合わせてデプロイメントを簡単に拡張する方法
→段階的に更新して、古いポッドを新しいポッドに徐々に置き換えることができる
→更新プロセス中にダウンタイムなしでアプリケーションを利用可能な状態が維持されます。
・再作成戦略
→既存のすべてのPodを終了し、再作成します。
→短時間のダウンタイムが発生します。

・新しいプロジェクトの作成

oc new-project deployment-demo

・httpdサーバのデプロイ

oc apply -f httpd-deployment.yaml

・httpdサーバのマニュフェストを書き換えて再度デプロイし、ローリングアップデートされていることを確認

vi httpd-deployment.yaml

oc apply -f httpd-deployment.yaml

oc rollout status deployment/httpd-deployment

・ロールバック

oc rollout undo deployment/httpd-deployment --to-revision=1

・ロールバックされていることをPodから確認

oc describe pod <podname>

・特定のリビジョン情報を表示

oc rollout history deployment/httpd-deployment --revision=2

※--revision=2を外して実行すると、リビジョンの履歴が表示されるので、それから指定すると良き

・レプリカ数を増やす

oc scale deployment/httpd-deployment --replicas=5

・ロールアウトのストップ

oc rollout pause deployment/httpd-deployment

・ロールアップの中止

oc rollout resumed deployment/httpd-deployment

ReplicaSets

目標

OpenShift管理者として、レプリカセットを管理する方法ついて理解する。

・レプリカセットはPodの数を一定に保つことで、アプリケーションにスケラービリティ、フォーr羽トレランス、高可用性を提供する。

・レプリカセットは、設定された数のPodを維持することでPodの可用性を確保するKubernetesリソースです。
・同一のPodを使用し、障害を許容し、更新をシームレスに処理します。
・Podのライフサイクルを管理し、宣言的な更新を提供するより高いレベルの抽象化です。
・Kubernetesのレプリカセットを理解すると、ワークロードの効果的なデプロイと管理についての洞察が得られます。
・ただし、デプロイメントはレプリカセットを管理し、宣言的な機能を提供する上位レベルの概念です。
　なので、普通はレプリカセットを直接操作するのではなく、デプロイメントを操作する。
・レプリカセットは、ラベルとセレクターを使用して、担当するPodを識別および管理します。

・練習用のyamlを用意

apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: my-replicaset
spec:
 replicas: 3
 selector:
   matchLabels:
     app: my-app
 template:
   metadata:
     labels:
       app: my-app
   spec:
     containers:
     - name: my-app-container
       image: bitnami/apache

・作ったyamlファイルでデプロイする

oc apply -f replicaset.yaml

・レプリカセットのステータスを確認

oc describe rs/my-replicaset

oc get rs

oc get pods

・レプリカセットのスケーリング（レプリカ数を5に変更）

oc scale rs my-replicaset --replicas=5

・レプリカセットのスケーリング（レプリカ数を2に変更）

oc apply -f replicaset.yaml

・レプリカセットの削除

oc delete rs my-replicaset

・deployment.yamlの作成

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: bitnami/apach:2.4
        name: my-app-container 

・deployment.yamlのapply

oc apply -f deployment.yaml

・ステータスの確認

oc get all

・コンテナイメージを最新バージョンへ更新する

oc set image deployment/my-app-deployment my-app-container=bitnami/apache:latest

ReplicaSets

目標

OpenShift管理者として、ラベルとセレクターを操作する方法ついて理解する。

・ラベルとセレクターを利用することによって、バージョン管理やロールバックなど、より効率的にリソースを管理することができる。

・yamlファイルの作成

apiVersion: v1
kind: Pod
metadata:
  name: my-labeled-pod
  labels:
    app: my-app
    environment: production
    tier: frontend
spec:
  containers:
  - name: my-cotainer
    image: bitnami/nginx

・Pod作成

oc create -f labeled-pod.yaml

・Podに割り当てられたラベルの表示

oc get pod my-labeled-pod --show-labels

・セレクターを用いてリソースをフィルタリング

oc get pods -l app=my-app

・環境ラベルと運用値またはステージング値を持つPodを選択します。

oc get pods -l 'environment in (production, staging)'

・ラベルの更新

oc label pod my-labeled-pod environment=staging --overwrite=true

・ラベルの削除

oc label pod my-labeled-pod tier-

Configure Services

目標

OpenShift管理者として、サービスの概念ついて理解する。

＜サービスの主な利点＞
・アプリケーションのフロントエンドとバックエンドを分離できること。これにより、コンポーネントのスケーリング、更新、保守が用意になる。
・負荷分散を行い、トラフィックが均等に分散されるようになる。

＜サービスのタイプ＞
・クラスターIP：クラスター内でIPアドレスとDNS名を提供する。（クラスター内部向け）
・ノードポート：クラスター内の各ノードの静的ポートでサービス自体を公開する。（クラスター外部向け）
・ロードバランサー
・ExternalName：外部名パラメータで指定された値を持つCNAMEレコードを返す。

＜用語の整理＞
・Bridge：ノード内の内部通信を担当し、クラスターノードに接続する。

・内部通信：クラスターIP→SDN→Bridge→Pod
・外部通信：物理ポート→ノードポート→クラスターIP→SDN→Bridge→Pod
・セッションアフィニティ：クライアントが特定のPodに接続された状態を維持するための仕組みです。これは特に、リクエストが複数のPod間で均等に分散されるように設計された負荷分散環境で有効です。セッションアフィニティを有効にすると、同じクライアントからのリクエストが常に同じPodにルーティングされるため、クライアントが状態を維持するアプリケーション（例：ショッピングカートやユーザーセッション管理）が必要な場合に便利。
・ヘッドレスモードとは、リソースやアプリケーションを特定のホストに結びつけず、名前解決のみを行うための設定モードです。これは通常、Serviceの一種として、クラスタ内の複数のPodにアクセスするために利用されます。OpenShiftやKubernetesの「ヘッドレスService」を設定することで、サービスのロードバランシング機能を無効にし、直接個々のPodに対して名前解決を行います。

Expose HTTP and non-HTTP applications to external access（HTTP および非 HTTP アプリケーションを外部アクセスに公開する）

目標

OpenShift管理者として、外部にアプリケーションを公開する方法を理解する。

＜HTTPアプリケーションの公開＞
・Routesを利用する

＜非HTTPアプリケーションの公開＞
・NodePortを利用する
・ロードバランサーサービスを利用する

＜デモ＞
・デモ用のプロジェクト作成

oc new-project httpdemo

・アプリケーションの作成

oc new-app --name=my-http-app --image=bitnami/nginx

・Podの起動確認

oc get pods -w

・Routeの作成

oc expose service my-http-app --hostname=my-app.httpdemo.apps-crc.testing

・作成したRouteの情報確認

oc get route

・作成したRouteの詳細情報確認

oc describe route my-http-app

MetalLB and Multus

目標

OpenShift管理者として、MetalLBとMultusを用いた高度なネットワーク機能を理解する。

・MetalLB→ベアメタルクラスター用のロードバランサー実装を提供し、サービスを公開できるようにする。
・Multus→複数のネットワークインターフェースをPodに接続できるため、柔軟な管理が可能になる。

OpenShiftにおけるMetalLBとMultusは、ネットワークの柔軟性と機能拡張を提供する重要なコンポーネントです。それぞれの役割を以下に説明します。

1. MetalLB: ロードバランシングの実現

役割

MetalLBは、Kubernetes環境（OpenShiftも含む）で、ロードバランサーの機能を提供するためのオープンソースのロードバランシングソリューションです。
クラウド環境で一般的なロードバランサー（AWSのElastic Load Balancerなど）と異なり、オンプレミス環境ではそのようなサービスが標準で提供されない場合があります。MetalLBはそのギャップを埋めるために利用されます。

主な機能

• LoadBalancer型サービスの実現:
  KubernetesのServiceリソースにおいて、type: LoadBalancerをサポート。
• IPアドレスの割り当て:
  指定されたIPレンジからサービスに外部IPを動的に割り当てる。
• 動作モード:
  • Layer 2モード: ローカルネットワーク内でARPを使ってIPアドレスを解決。
  • BGPモード: BGP（Border Gateway Protocol）を利用してルーターにIPアドレスをアドバタイズ。

OpenShiftでの活用例

MetalLBを利用することで、オンプレミス環境においても外部からサービスにアクセス可能なロードバランサーを提供でき、OpenShiftクラスターのネットワークをクラウドのように扱えるようになります。

2. Multus: マルチネットワークの実現

役割

Multusは、KubernetesやOpenShiftで複数のネットワークインターフェースをPodに割り当てるためのCNI（Container Network Interface）プラグインです。デフォルトのネットワークに加え、追加のネットワークを柔軟に設定できます。

主な機能

• マルチネットワークの提供:
  1つのPodが複数のネットワーク（例: デフォルトネットワーク + ストレージ用ネットワークなど）を利用可能。
• カスタムネットワークの追加:
  例えば、SR-IOV（Single Root I/O Virtualization）やその他の特殊なネットワークを構成。
• ネットワーク分離の実現:
  セキュリティやパフォーマンス要件に応じたネットワークの分離。

主な構成要素

• NetworkAttachmentDefinition:
  カスタムリソースとして定義され、Podにアタッチされる追加ネットワークの仕様を記述。

OpenShiftでの活用例

• ネットワーク分離:
  フロントエンドとバックエンド用のネットワークを分離してトラフィックを最適化。
• 特殊用途のネットワーク:
  高性能なネットワークや外部ストレージとの通信専用ネットワークを構築。

まとめ

これらを組み合わせることで、オンプレミスのOpenShiftクラスターにおけるネットワークの柔軟性と拡張性を大幅に向上させることが可能です。