2021年11月14日日曜日

各種APIについて

手順:

1)以下のコマンドで、APIを確認する。


kubectl api-resources 



環境切り替え for k8s

以下の環境(k8s)があるので、必要に応じて切り替えを行いたいと思う。

1)docker-desktop(Mac)

2)Raspberry pi



手順:

1)Mac側の以下のファイルにRaspberry piの環境を追加する。

  ->青枠(Raspberry pi)のconfigを追加する


注意)

赤枠のcurrent-context:については、触れないこと!


~/.kube/config








2)追記を終えたら、docker desktopのメニューからkubernetes > Contextを選択して

必要に応じて、環境の切り替えが行えるようになる。




2021年11月12日金曜日

Podの安全に終了させるタイミングについて

リクエスト時間での対策:
terminationGracePeriodSecondsの設定を行うことで安全な終了対策が行える


アプリ側でリクエスト処理が別途必要な場合:

アプリ側での工夫が必要。

手順:


以下のような、停止処理に100秒かかるコマンドがあった場合

何も設定してない状態だと、30秒で強制的にPodがKILLされてしまいます。


<イメージ図>




























terminationGracePeriodSecondsの設定することで

100秒処理が終了してから、Podを安全に終了させることができます。

(terminationGracePeriodSecondsのデフォルト値は30秒になる)



postStart/preStop

postStart/preStop :
コンテナの起動と終了時に、コマンドを投入する方法になる。


<イメージ>

①Podのデプロイ時に、スリープ100秒 ->startedのファイルを作成

②postStart:poststartのファイルを作成

③preStopprestopのファイルを作成



























podのデプロイ後に、作成したファイルが出来ているか確認する。

(poststart, startedというファイルが作成していることが把握できる)





podを削除するタイミングでファイルを確認する

(poststopというファイルが作成していることが把握できる)






VS Code(snipets)

スニペット作成サイト
https://migi.me/vsc_snippet/


手順:

1)基本設定  >  ユーザースニペット















2)スニペット名を記載する









3)以下の枠内に、json形式で記載を行う

(例では、”prefix”: initContainersの題名で記載を行なった)













































4)作成後、キーボードで  “  i “と入力すると予測機能で先ほど作成した

スニペットが表示されるので、選択を行うだけ。



init Container

参照:
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)を行う

①output2index.htmlに書き込み(2st-test)を行う



























ブラウザ上でも確認















コマンド上でも確認する。



restartPolicy

コンテナのプロセス停止時、またはヘルスチェックで失敗時にspec.restartPolicyで
指定することができる。

①Always       : ヘルスチェック失敗時にPodを再起動させる

②OnFailure  : Podでコマンドが失敗したら再起動を行う 

③Never         : ヘルスチェックでNGでもPodが再起動させない


labels(mathLabels)

参考:
https://cstoku.dev/posts/2018/k8sdojo-08/



wordpressとMySQLの連携について考察する。


①mathLabelsでお互い(wordpress/MySQL)のlabelを指定することで連携を図る。

②作成したMySQLのサービス名(wordpress-mysql)を指定する。

WORDPRESS_DB_HOSTwordpressDBの接続先に関する環境変数になる。


































Secret for k8s(2)

公式:
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 / Readiness Probe

 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まとめ

 以下、Autoscalerについて記載する。

①HorizontalPodAutoscaler(HPA):

Podをオートスケーリングする機能




















②Cluster Autoscaler:

Nodeのリソース枯渇によりPodの配置できない場合に

新規のNodeが追加される機能



2021年11月2日火曜日

HorizontalPodAutoscaler(HPA)

公式(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)に戻ったことが把握できます。





EFS(Dockerfile)の記載について注意

  Dockerfileにefsのマウントパス宛に、ファイルコピーを行うと ECSのサービス作成時に、コンテナのデプロイ失敗に(container run time error)になるので 別経由で、EFSにファイルをコピーした方が良い!! <Dockerfile> ...