OpenShift Container Platform 勉強メモ②

docker kubernetes openshift

学習内容

  1. OpenShift CLIコマンドについて
  2. リソースへのアクセスの制御
  3. 永続ストレージについて

4. OpenShift CLIコマンドについて

トラブルシューティング

コマンドを使ったトラブルシューティング。
【問題】
とあるプロジェクトで内部レジストリに用意されたイメージを使ってnew-appを実行するも
イメージストリームタグの誤りに関するエラーが出力される

$ error: multiple images or templates matched "php:5.6": 2

【シューティング】
os describeコマンドで有効なタグを一覧表示する。

$ oc describe is php -n openshift

出力結果として、php:5.6イメージが使用できないため無効であるという出力がされる。

php:7.0でデプロイ。

$ oc new-app --name=hello -i php:7.0 http://XXX/php-helloworld

コマンドは成功。podの状態を確認

$ oc get pods -o wide

出力結果として、podがPending状態でアプリが起動していないことを確認

podのログを確認

$ oc logs (対象pod名)

出力結果無し。次にプロジェクトのイベントログをチェック。

$ oc get events

または、podの詳細を確認

$ oc describe pod (対象pod名)

いずれの出力結果からも、FailedSchedulingが出力されていることを確認

各Nodeの状態を確認

$ oc get nodes

出力結果より、node1とnode2がNotReady状態なのを確認

node1、node2それぞれでatomic-openshift-nodeサービスの状態を確認

$ systemctl status atomic-openshift-node -l

atomic-openshift-nodeサービス自体はアクティブだが、ログよりdockerデーモンに問題があることを確認。調べる。

$ systemctl status docker -l

出力結果より、起動していないことを確認。両方のnodeで起動

$ systemctl start docker

再度、各Nodeの状態を確認

$ oc get nodes

Readyになったこと確認。podを確認。

oc get pods

Running状態になったことを確認。解決。

5. リソースへのアクセスの制御

Openshiftのセキュリティ機能を利用して、リソースへのアクセスを制御

リソースの分離

まず、そもそものリソースの分離は、project単位で分離
　⇒kubernetesでいうネームスペース。

クラスター管理

クラスター管理者(openshift全体の管理者)が任意のユーザに作ったプロジェクトの管理権限を委任することができる。プロジェクト自体を作成する権限も割りあてが可能。

プロジェクトの作成権限は、self-provisionerクラスターロールを追加・削除することで割り当て可能。

例：追加する場合

$ pc adm policy add-cluster-role-to-group self-provisioner system:authenticated system:authenticated:oauth

ユーザタイプ

ユーザは大きく分けて3タイプある。

・一般ユーザ
・システムユーザ
クラスター管理者、ノード、ルーター、レジストリが使用するユーザなど
・サービスアカウント
特別なシステムユーザ。podを起動するときの特別なアカウント。
例えば、root権限でないと起動できないコンテナとかある。そういうときにサービスアカウント作ってそれで起動させる。

SCC(セキュリティコンテキスト制限)

podが実行できるアクションとアクセスできるリソースを制御する。
デフォルトでいろいろ用意されている。

メンバーシップ管理

一般ユーザはGUIコンソール上でもコマンドライン上でも自由に作れますよ。
ただ、ユーザ情報にも登録してあげよう。(例えば、ファイル管理だったらhtpasswdとかで。)

secret

podに機密情報(リポジトリー資格情報とか)を環境変数として渡せる。
内部的に変数を符号化する。でも簡単に平文に戻せるｗ

・定義

$ oc create secret generic test-secret --from-literal=username(key)=test-user(value)

・利用

env:
 - name: MYSQL_USER
   valueFrom:
    secretKeyRef:
     key: username
     name: test-secret

config Map

secretと役割変わらない。違いがあるとしたら符号化されていないだけ。

ぶっちゃけ、GUIコンソールでpod立ち上げるときに環境変数は指定できる。
ただ、複数podを立ち上げるってなったら設定変更は大変。
⇒configMapはdc自体に定義するものだから、それにぶら下がるpodは全て設定した環境変数が使える。
⇒複数pod立ち上げるときは、configMapを使おう的な。

6. 永続ストレージについて

基本的にコンテナは、コンテナ内の揮発性ストレージを利用。
⇒つまり、コンテナを再起動すると情報は失われる。
⇒そこで永続ストレージの登場。マウントさせて再起動しても情報が失われないようにする。

登場人物

・永続ボリューム(PV)
クラスタ内のリソース。外部ストレージとプロビジョニングしてクラスタ内でそのストレージのリソースを利用できるようにする。
・永続ボリュームクレーム(PVC)
podが永続ボリュームをクレーってやる設定。

永続ストレージについて

NFSとかAWS EBSとかいろいろ対応している。
3.5系は少ない。3.10系からいろいろ追加されてた。

PVのアクセスモード

３つある。
・ReadWriteOnce(RWO)
単一のノードによる読み取り、書き込みが可能なようにボリュームをマウント
・ReadOnlyMany(ROX)
複数のノードによる読み取りのみが可能なようにボリュームをマウント
・ReadWriteMany(RWX)
複数のノードによる読み取り/書き込みが可能なようにボリュームをマウント

永続ストレージがAWS EBSとかでROXなんかにしちゃうと壊れちゃうから注意
⇒外部ストレージが何かによってどのアクセスモードを使うか意識する必要がある。

内部レジストリの永続化について

S2Iビルドによって、生成されたイメージは内部レジストリにプッシュされるが、
ホストノードの再起動とかで、レジストリポッドが再生成されたあとにそのイメージ消えちゃう。

インストーラでOpenShift構築すると、デフォルトのレジストリが設定されているかつ、マスターからエクスポートされたNFS共有が使用されるが、
耐障害性と高可用性のために、外部ストレージにマウントさせることを推奨している。

ハンズオンで、PVやPVC作ってマウントさせたりした。