手順:
1)以下のコマンドで、APIを確認する。
kubectl api-resources
以下の環境(k8s)があるので、必要に応じて切り替えを行いたいと思う。
1)docker-desktop(Mac)
2)Raspberry pi
手順:
1)Mac側の以下のファイルにRaspberry piの環境を追加する。
->青枠(Raspberry pi)のconfigを追加する
注意)
赤枠のcurrent-context:については、触れないこと!
~/.kube/config
2)追記を終えたら、docker desktopのメニューからkubernetes > Contextを選択して
必要に応じて、環境の切り替えが行えるようになる。
リクエスト時間での対策:
terminationGracePeriodSecondsの設定を行うことで安全な終了対策が行える
アプリ側でリクエスト処理が別途必要な場合:
アプリ側での工夫が必要。
手順:
以下のような、停止処理に100秒かかるコマンドがあった場合
何も設定してない状態だと、30秒で強制的にPodがKILLされてしまいます。
<イメージ図>
terminationGracePeriodSecondsの設定することで
100秒処理が終了してから、Podを安全に終了させることができます。
(terminationGracePeriodSecondsのデフォルト値は30秒になる)
postStart/preStop :
コンテナの起動と終了時に、コマンドを投入する方法になる。
<イメージ>
①Podのデプロイ時に、スリープ100秒 ->startedのファイルを作成
②postStart:poststartのファイルを作成
③preStop:prestopのファイルを作成
podのデプロイ後に、作成したファイルが出来ているか確認する。
(poststart, startedというファイルが作成していることが把握できる)
podを削除するタイミングでファイルを確認する
(poststopというファイルが作成していることが把握できる)
参照:
https://kubernetes.io/ja/docs/concepts/workloads/pods/init-containers/
https://cstoku.dev/posts/2018/k8sdojo-06/
init Container :
セットアップ専用のデータを保持したく無い場合に
有効な初期導入時にのみ稼働するコンテナになる。
手順:
以下、init Container を2個作成してみた。
<イメージ>
以下の流れで、上から順番にコンテナが稼働するため
順番どおりに処理を稼働させたいなど目的に一致したこともできる。
①output1がindex.htmlに書き込み(1st-test)を行う
①output2がindex.htmlに書き込み(2st-test)を行う
ブラウザ上でも確認
コンテナのプロセス停止時、またはヘルスチェックで失敗時にspec.restartPolicyで
指定することができる。
①Always : ヘルスチェック失敗時にPodを再起動させる
②OnFailure : Podでコマンドが失敗したら再起動を行う
③Never : ヘルスチェックでNGでもPodが再起動させない
参考:
https://cstoku.dev/posts/2018/k8sdojo-08/
wordpressとMySQLの連携について考察する。
①mathLabelsでお互い(wordpress/MySQL)のlabelを指定することで連携を図る。
②作成したMySQLのサービス名(wordpress-mysql)を指定する。
WORDPRESS_DB_HOST:wordpressのDBの接続先に関する環境変数になる。
公式:
https://kubernetes.io/ja/docs/tasks/configmap-secret/managing-secret-using-config-file/
user : root
Pass : 4126@Music
<手順>
1)user名とPasswordをbase64形式にエンコード化する。
例:
echo -n ‘root’ | base64
echo -n ‘4126@Music’ | base64
2)エンコードした情報をベースにsecretoの作成を行う
メモ:
ちなみにbase64形式のエンコード化しないでsecretのデプロイを行うと
エラー表示が出て作成できない状態になる。
Liveness Probe(立ち上げ前チェック):
正常に動作しているか確認するためのヘルスチェック
->失敗している場合、Podを再起動
Readiness Probe(立ち上げ後チェック):
Podがサービスインしている準備が出来ていることを確認するためのヘルスチェック
->失敗している場合、トラフィックを流さない。
[ヘルスチェック方式]
以下、3パターンになる。
①exec :コマンドを実行して終了コードが ” 0 ”でなければ失敗
②httpGet :HTTP GETリクエストを実行して、Status Codeが200から399でなければ失敗
③tcpSocket:TCPセッションが確立できなければ失敗
注意点:
指定したフォルダーとファイルがコンテナ上に実在すること!
[ヘルスチェックの間隔]
initialDelaySeconds : 初回ヘルスチェック開始までの遅延
timeoutSeconds : タイムアウトまでの秒数
successThreshold : 失敗と判断するまでのチェック回数
failureThreshold : 成功と判断するまでのチェック回数
periodSeconds : ヘルスチェックの間隔
<マニュフェストの作成>
Liveness Probe :index.htmlに対して、http getを要求したヘルスチェックを行う。
Readiness Probe :50x.htmlが存在をトリガーにヘルスチェックを行う
以下、Autoscalerについて記載する。
①HorizontalPodAutoscaler(HPA):
Podをオートスケーリングする機能
②Cluster Autoscaler:
Nodeのリソース枯渇によりPodの配置できない場合に
新規のNodeが追加される機能
公式(HPAについて) :
https://kubernetes.io/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
必要な物(metrics-server) :
->podからのメトリクスを収集を行う。
https://github.com/kubernetes-sigs/metrics-server
helm(metrics-server) :
https://artifacthub.io/packages/helm/metrics-server/metrics-server
マニュフェストの作成:
1)HPA用のconfigを作成する。
name : テスト用のPodの名前(webapp)を指定
minReplicas : 最小値
maxReplicas : 最大値
targetAverageUtilization : スケーリングするためのトリガーになる。(今回の場合は、cpu使用率)
2)テスト用のPodを作成
検証:
1)metrics-serverを導入後に、以下のコマンドを投入してメトリクスの確認を行ってみる。
2)念の為、作成したHPAのコンフィグの状態を確認したところ
Podからのリソースを受信できているようだ。
3)jmeterを使って、作成したLaodBlancerに高負荷をかけてみます。
4)高負荷①をかけてみると、②Replicasが最大5台に増加していることが把握できます。
5)数分経過すると、自動的にスケールイン(最小: 1台)に戻ったことが把握できます。
# PHPエラーログの設定 ENV PHP_INI_DIR /usr/local/etc/php RUN { \ echo 'log_errors = On' ; \ echo 'error_log = /proc/self/...