■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リソース]
クラスタ内のリソースの動作を制御するリソース
