手順：
topコマンドでロードアベレージを確認する。
確認方法：
左から1分、5分、15分の平均値を表している
利用しているPCのCPUが4コアなので4以下の数値であれば、問題ない水準。
（仮に、数値が4を超える場合、CPUの処理が追いついてない状況が想定される。）
<IO>
%iowait：
「CPUがアイドル状態で、システムに未処理のディスク入出力要求があった時間の割合」
確認方法：
以下のコマンドでIOの確認を行う
sar 5 10
(50の数値を超えないなら正常値)
<CPU負荷が高い場合のI/O待ちを確認>
確認方法：
以下のコマンドで確認する。
（mmcblk0 ：SDカード ）
iostat -x
メリット：
大抵は、モニタリングツール上でログの検索が出来ると思うが
ターミナル上（その場で）で、サクッと確認したい場合に便利かと思う。
手順(Macの場合)：
1)以下のコマンドを投入する。
brew install stern
2)使い方はシンプルで以下のように行えば良い
stern [pod名]
（以下、対象のpodからログが出力されていることが把握できる。）
参照先：
https://kubernetes.io/ja/docs/tasks/debug-application-cluster/get-shell-running-container/
kubectl exec -it [pod名] --[コマンド] ….[ コマンド]
検証：
ラベル(sample-app)のpodに対して、pod数を3つに指定した場合
追加用のマニュフェストで同一ラベル(sample-app)をデプロイ後の動作検証を行う。
■３台構成のマニュフェスト作成
1)以下、3台構成のpodを作成
ラベル名：sample-app
(ファイル名：test-nginx.yaml)
2)作成状況を確認
■追加用Podのマニュフェスト作成
1)以下、同一のラベル名のマニュフェストを作成
タグ名：sample-app
(ファイル名：test-nginx2.yaml)
2)マニュフェスト(test-nginx2.yaml)を実行します。
結果：
3台のpodを維持するために、追加用マニュフェストのデプロイが出来ない。
前置き：
CI/CD経由で、戻すことが前提の場合
以下の方法で戻すメリットは薄いかと考える
(あくまでも技術メモになる)
手順：
以下の更新前の状態に戻す。
1)現在の更新履歴を確認する
kubectl rollout history deployment “metadataの値” --revision [数値]
リビジョン指定：
1)リビジョンを指定して、ロールバックを行う。(revision3に戻してみる。)
kubectl rollout undo deployment nginx-test --to-revision 3
一つ前にロールバック：
kubectl rollout undo deployment nginx-test
以下、ローリングアップデートについて、マニュフェストでの
記載方法を提示する。
(マニュフェストに記載がなくてもReplicasの指定があればデフォルトで
ローリングアップデート行ってくれる)
以下、用語について記載する。
1)maxSurge ：一度に超過可能なPod数
2)maxUnavailable ： 一度に停止可能なPod数
実施内容：
1)ローリングアップデートを行う際の何個ずつ更新を行いたかを
指定したい場合、以下のように記載が必要になる。
(maxSurge: にアップデートを行う際に追加したいPod数を記載)
2)以下、実施してみる、新バージョンのPodが２個追加されたのが把握される。
3)この後、更に２個のPodが追加されて合計４台のPodが更新されて完了となる。
4)以下、maxUnavailable：の数値を記入した場合。
更新時に旧バージョンのPodを削除する数を決めることができる。
5)実行してみると、以下のように旧バージョンのPodが３台削除されていることが把握できる
statefullSetのリソースを利用して、ローリングアップデートを行う場合
以下の方法で、更新できる上限を決めることができる。
（要は、５台中/２台までと制限することができる）
1)以下のpartitionを記載する。
（以下の場合、5台中->2台まで更新を行い、残り３台は更新を行わない。）
以下、実施の様子。
■kubenetesで出来ること。
以下のことが出来るので、シンプルにDockerの実行するより
管理＆運用コストが低いことが把握できる。
特徴：
①コンテナのスケジューリング
②ローロングアップデート
③スケーリング・オートスケーリング
④コンテナの死活監視
⑤障害時のセルフヒーリング
->k8sの醍醐味で、指定したコンテナ数を維持する仕組みになっていて
仮に３台中/一台のコンテナが落ちた場合、新規で１台作成される仕組み
⑥サービスディスカバリ
->内部DNS機能で、各登録したマイクロサービスを連携するのに利用する。
⑦ロードバランシング
⑧データ管理
⑨ワークロードの管理
⑩ログ管理
⑪Infrastructure as Code
->yaml形式のファイルでシステムの構築が行える
⑫その他システムの連携、拡張
■Master（コントロールプレーンとも呼ぶ）
特徴：
①ローカル環境に対してのAPIを提供
->ローカル環境または、CI/CDからマニュフェストをAPI経由でMaster側に登録（管理する）
②スケジュリングを行う
->どのノードのコンテナを配置するのかなど
③スケーリング・オートスケーリングを行う。
■Node（データプレーンと呼ぶ）
特徴：
コンテナを実行する基盤
[Wordloadsリソース]
概要：
コンテナを起動するのに利用するリソース。
以下の分類になる。
1)Pod
2)ReplicaSet
指定したPod数を維持するリソース
（Deployment経由で利用する）
3)Deployment
ローリングアップデート、ロールバックなどを実現するリソース
->こちらのリソースを利用することが多い。
4)DemonSet
各ノードにPodを1つずつ配置するリソース
->監視系、Podのデータ変換、カオスエンジニアリングなどの各ノード毎に配置が必要な場合に優位
5)Job
一度限りのコンテナ処理を行いたい場合に利用するリソース
->時刻指定ができるCronJobのがメリットが多いかと個人的には考える。
6)CronJob
スケジュールされた時間にコンテナ処理を行いたい場合に利用するリソース
->cron的な用途になるので、JobよりCronJobのが有効かもしれない。
総括：
自作のアプリや運用上のバッチ処理を行う観点でいうと
DeploymentやCronJobが使い勝手が良さそう。
[Discovery&LBリソース]
コンテナのサービスディスカバリやクラスタの外部アクセス可能なエンドポイントを提供するリソース
[Config&Strageリソース]
設定や機密データをコンテナに埋め込みや永続ボリューム(ストレージ)を提供するリソース
①Secret(機密情報)
②ConfigMap(設定関連)
③PersistentVolumeClaim(ボリューム系)
[metadataリソース]
クラスタ内のリソースの動作を制御するリソース
概要：
一度限り実行可能なコンテナの実行を行うのに最適なリソース
[手順]
1)1分毎に、メッセージが出力するマニュフェストを作成してみる。
schedule:
１分毎に稼働する
concurrencyPolicy:
同時実行に関するポリシー
①Allow: 同時実行に対して制限を行わない
②Frbid: 同時実行を行わない
③Replace: 前のJobをキャンセルしてJobを実行する
suspend:
CronJobの一時停止を行いたい場合に指定。
①true：cron停止
②false: cron稼働
completions:
成功回数を指定する
parallelism:
並列度を指定する
backoffLimit:
失敗を許容する回数
2)実際結果が以下になる。
1)対象の範囲を選択
2)Command + { or } で選択範囲を移動できる。
以下のように、選択範囲をまとめて、移動することが出来た。
