スキップしてメイン コンテンツに移動

OpenShift学習メモ with 公式ドキュメント

一通り学習を終えたので復習と落穂拾いを兼ねて公式ドキュメントを読み返した。

時短のために今回は日本語翻訳版を読んでる。

サービスアカウント:

* プロジェクトではデフォルトで3つのサービスアカウントが自動的に作られる
* builder:ビルドのPodで使用される。system:image-builderロールが付与される。このロールによってビルド結果を内部のレジストリーからプロジェクトのイメージストリームにプッシュ可能にしている
* deployer:デプロイメントのPodで使用される。system:deployerロールが付与される。このロールによってレプリケーションコントローラーやPodを表示したり変更したりできる。
* default:指定されない限りその他全てのPodで使用される。
* この他、すべてのサービスアカウントには system:image-pullerロールが付与される。このロールは内部のレジストリーを使用してイメージストリームからイメージをPullすることを可能にしている。

この最後のimage-pullerロールは学習コンテンツ内でも使われていた。具体的には、共通で使用する用のイメージストリームを持つプロジェクトを作成、他のプロジェクトのimage-pullerロールに、当該共通用のイメージストリームからpullできるように権限をセットするというもの。

oc policy add-role-to-user system:image-puller system:serviceaccount:project-a (--namespace=project-b)のようにすればproject-bのイメージを参照可能なロールがproject-aに所属するすべてのユーザーにつく。


ストレージ管理:

* PV:クラスター管理者がクラスターの永続ストレージのプロビジョニングを実行できるようにする。
* PVC:開発者がPVを使用するための手段として作成して使用する。PVがPVCにバインドされると、そのPVは使用できるスコープが特定のnamespaceに限定されるなどの作用があり、PVCにバインドされたPVは他のPVCに追加ではバインドできない。

実際に使うための仕様を確認すると、PVが例えばRWX(読み書き同時複数許容)の20GBとして作成されると。その後PVCが例えばRWXで、5GB以上のストレージのあるPVがほしい、と宣言すると、その条件に合致したPVがバインドされる様子。
だとすると、このPV・PVCを使いたいケースというのはどういう時なのだろう。
自分が使おうとしていた時は、あるPod AとあるPod Bの間でデータを共有したい、Pod AはReadだけだけどWebサーバーのインデックス表示のような形で表示したい、Pod BはWriteだけしたい、処理結果を出力するようなイメージ。

でもこのような使い方だと、ある同じストレージに対して複数PVを作り、それを上記Pod AとPod BでそれぞれPVCとして指定して呼び出すような使い方になる。
自分の場合はPVCのYAML内にPVも指定して書いてしまい、それをPodで指定して使ったので問題にならなかったけれど、仕様が期待している宣言が入った時にPVを探すような形にしてしまうとこのやり方では破綻する可能性がある。

となると、PVCが使われるシチュエーションは特定のPodの中のコンテナ間でデータを共有したい時、とかなのだろうか。もう少しちゃんと理解した方が良さそう。


OCのプラグイン拡張:

* 現在この機能はTech Preview段階(As of 4.5)。
* プラグインとして認識させるためにoc-, kubectl-から始まる名前でファイルを作る。oc-foo-barとするとoc foo barというコマンドで呼べるようになる。oc foo_barとすれば oc foo-barのようにコマンド側にハイフンを含められる。

BashやGoなど作成例も複数あり、単純なことをやりたいならそれほど作成は苦なく実現できそう。(そもそも単純なことの場合プラグインを作る必要もないのだろうけど)


その他コマンド類:

* oc auth can-i get pods --subresource=log のようにすると、podのログを読み取る権限があるかチェックできる
* oc cluster-info マスターおよびクラスターサービスのアドレスを表示する
* oc registry info 統合レジストリーの情報を表示する(レジストリーに対してはサブコマンドのオプションがさらに用意されているため, cluster-infoのようになっていない様子)
* oc convert -f pod.yaml YAML・JSONの設定ファイルを異なるAPIバージョンに変換する
* oc extract configmap/ruby-1-ca ConfigMapやSecretの内容を抽出してファイルにダウンロードしたり標準出力したりする
* oc image mirror myregistry.com/myimage:latestmyregistry.com/myimage:stable イメージを別のタグにコピー
* oc observe serivces リソースの変更を監視する ヘルプを見るとobserveで変更があるたびに更新が標準出力で受け取れる、この変更のたびに特定のスクリププトを流す、ということが想定されている様子で、例えばアノテーションを追加したり、別で管理しているノードのリストを更新したり、と言った用途に使える
* oc patch node/node1 -p '{"spec":{"unschedulable":true}}' 特定のフィールドなどを更新する, カスタムリソース定義(=kindに新しい種類を追加するようなやつ)のパッチを適用する場合には--type mergeが必要とのこと
* oc replace -f pod.json 既存のリソースを指定したファイルを使って置き換え(どう置き換えているのかが調べても分からなかった。おそらく.metadata.uid、次いで.metadata.nameと.metadata.namespaceを見て置き換え対象を引っ掛けている、か?)
* oc completion bash bash-completionを標準出力する, 別ファイル保存してからbashrcなどで読ませてあげればocの後の補完が効くようになる

普段自分はあまり使わないがドキュメントを読んで知った・使う機会が増えた類をとりあえず列挙してみた。


おまけ:

* new-appコマンドで作られるサービスでは、インプットイメージの公開ポートの中で最も低い数値のものを使用する(つい最近引っかかったやつだ!)ちなみに、new-appが作るのはdeployment(config), service, imagestream。 
* デフォルトのOpenJDK設定はコンテナ内では機能しないため、コンテナーで OpenJDK を実行する場合は常に追加のJava メモリー設定を指定する必要がある。(だからQuarkusのUbi8のイメージだといっぱいオプションがついていたのか......と今更ながら)最低限次のタスクは必要とのこと。 ref https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.5/html/nodes/nodes-cluster-resource-configure#nodes-cluster-resource-configure-jdk_nodes-cluster-resource-configure
  1. JVM最大ヒープサイズを上書きする。
  2. JVMが未使用メモリーをオペレーティングシステムに解放するよう促す(適切な場合)。 
  3. コンテナー内のすべてのJVMプロセスが適切に設定されていることを確認する。
* OpenShiftにある仮想グループとして次の3つが用意されている。
  * system:authenticated(認証済みユーザー)
  * system:authenticated:oauth(OAuthアクセストークンで認証されたユーザー)
  * system:unauthenticated(認証されていないユーザー)
  * Topologyビューでサービス間をつなぐことでDeploymentの環境変数に接続情報(e.g. DB)が挿入されて再デプロイされる、という機能が現在プレビュー段階として用意されている。(OpenShiftに馴染みのないユーザーにとっては便利そう)
* Topologyビューに表示されるアイコンはapp.openshift.io/runtime、app.kubernates.io/nameのラベルから探されるなど、付与されたラベルの値によってリンク含め制御されている。
* ocでBlue-Greenデプロイメントをする場合、Blue・Greenをそれぞれ稼働後に、routeをpatchなどで編集しspecのServiceをGreenからBlueに切り替える、などのようにすることで実現できる。
* ocでA/Bテストやカナリアリリースを実現する場合、routeの中にweightを指定することで、既存ルートへの重み付けを実現できる。
* GitHub等ソースコード管理のサーバーへの認証はHTTPSの場合はkubernetes.io/basic-authのタイプのシークレットを使う、SSHの場合はkubernetes.io/ssh-authのタイプのシークレットを使う。