Probe,Service,Secret,HPA

■全体概要

Kubernetesコンポーネントの構造と動作原理

1. リソース自動化の核心：オブジェクトとコントローラー

k8sインフラには、ネットワーク、ボリューム、環境変数など、数多くの要素が存在する。k8sはこれらの要素を**オブジェクト（Object）として定義し、それらを自動化するためにコントローラー（Controller）という概念を導入した。

• 動作方式: コントローラーは、ユーザーが宣言した「あるべき状態（Desired State）」を常に監視し、ネットワークやボリュームなどがその状態を維持するように継続的に管理・調整を行う。

2. 頭脳の役割：コントロールプレーンコンポーネント (Control Plane Components)

リソース全体を動かすエンジンとなるのがコントロールプレーンコンポーネントである。これらは主にマスターノード上でPodとして動作し、クラスター全体の意思決定を担当する。

• 相互作用: 各コンポーネント（API Server、Scheduler、Controller Managerなど）は独自の役割を持ち、リソースを動作させるために互いに絶え間なく通信を行う。

3. 実行の実体：コンテナランタイム (containerd)

ここで非常に重要なポイントがある。コントロールプレーンが命令を下すものの、実際にコンテナを作成するのはk8sではない。

• 生成要請: k8sは「このようなコンテナが必要だ」という生成要請を送るだけである。
• 実際の制作: その要請を受け取り、実際にコンテナを駆動させるのはcontainerdなどのコンテナランタイムの役割である。

---

■Pod生成およびprobe

1.認証と検証 (kubectl → API Server)

• Authentication (認証)： API Serverが証明書(kubeconfig)を確認し、「正規のユーザーか？」を認証する。
• Authorization (認可)： 「該当のNamespaceにPodを作成する権限(RBAC)があるか？」をチェックする。
• Admission Control： Podの設定がセキュリティポリシーに適合しているかを検証する。必要に応じて内容を書き換えたり(Mutating)、拒否(Validating)したりする。

2. 状態維持の指示 (Controller Manager)

• 役割： ユーザーがDeploymentなどをデプロイした場合、Controller Managerがこれを検知する。
• 動作： 「あるべき状態(Replicas:3)」と「現在の状態(0)」を比較し、不足しているPodを作成するようにAPI Serverへ要請を送る。すなわち、Pod生成をトリガーする自動化エンジンである。

3. 状態保存 (API Server → etcd)

• すべての検証が完了すると、API ServerはPodの定義内容をetcdに書き込む。
• 核心： この時点でのPodの状態はPendingである。まだどのノードに配置されるかも決まっていない、純粋な「データ」としての状態だ。

4. スケジューリング (Scheduler)

• SchedulerはAPI Serverを常に監視(Watch)しており、「ノードが割り当てられていない(nodeNameが空の)新しいPod」の存在を検知する。
• 各ノードのリソース状況を計算して最適なノードを選択し、その情報をAPI Serverに伝える。API Serverはそれを再びetcdに反映する。

5. 実行命令 (Kubelet)

• 該当ノードのKubeletもAPI Serverを監視しており、「自ノードに割り当てられたPod」を認識する。
• Kubeletは直ちに**CRI(Container Runtime Interface)**を通じてコンテナ(containerd)を生成し、**CNI(Container Network Interface)**を通じてPodにIPを割り当てる。

6. ネットワーク開通 (kube-proxy)

• 役割： Podが正常に生成されIPが割り当てられると、kube-proxyがこの情報を検知する。
• 動作： ユーザーがサービス(Service)経由でこの新しいPodにアクセスできるよう、各ノードのネットワークルール(iptables/IPVS)を更新する。すなわち、通信経路を確保する道路舗装担当である Academy。

7. 状態報告 (Kubelet → API Server)

• Podが無事に起動すると、Kubeletは「正常に起動した(Running)」とAPI Serverに報告し、最終的な状態がetcdに保存される。

8. 継続的なヘルスチェック (Probeの実行)

Podが実行された後、Probeの設定がある場合、Kubeletは設定に従ってコンテナに対して定期的にヘルスチェックを実行する。

アプリ機能の理解 - Pod（Probe）

---

■Service

1. サービスとネットワークの動作フロー

• エンドポイントの管理 (Service to Pod): サービスは Selector を通じて該当する Pod 群を識別し、その IP アドレスを Endpoints オブジェクトとして常に最新の状態に維持する。
• ネットワークルールの監視 (kube-proxy): kube-proxy は API Server を監視し、新しいサービスやエンドポイントの情報を受け取ると、各ノードにその情報を反映させる。
• iptables の更新 (Mapping Rules): kube-proxy は各ノードの iptables（Linux カーネルのパケットフィルタリング機能）に、「サービス IP へのアクセスを実際の Pod IP へ転送する」というマッピングルールを追加する。
• パケットの転送と経路確保 (CNI & Kernel): 実際のトラフィックが入ってくると、Linux カーネルが iptables のルールに従ってパケットの目的地を書き換える。CNI (Container Network Interface) は、あらかじめ Pod が通信できるように仮想ネットワークインターフェース（veth pair）を構築し、パケットがコンテナまで届くための「道」を完成させておく。

---

■Secret

 

1. Secret の動作メカニズムとコンポーネントの役割

• メモリベースのマウント (tmpfs): Pod に Secret をボリュームとしてマウントすると、そのデータはノードの物理ディスクではなく tmpfs (RAM ディスク) 領域に配置される。これは、ノードの再起動時にデータを消去し、機密情報の漏洩を防ぐためのセキュリティ対策である。
• リソース消費の注意点: Secret 自体は etcd に保存されるが、大量の Secret を多くの Pod にマウントすると、その分ノードの メモリ（RAM）を消費 することになる。極端に巨大なデータを Secret として扱う場合は、メモリ不足（OOM）のリスクを考慮する必要がある。
• Kubelet による動的更新: Kubelet は定期的に API Server を監視（Watch）しており、マウントされた Secret に変更があった場合、Pod 内のファイルを 自動的にアップデート する。
  • 注意: ボリュームとしてマウントした場合は自動更新されるが、環境変数 (Environment Variables) として注入された場合は、Pod の再起動なしには反映されない。

---

■HPA

 

1. リソース使用量の把握 (データソース)

コンテナ単位の個別のリソース使用量は、コンテナランタイムである containerd が把握している。これがすべてのメトリクスデータの起点となる。

2. メトリクスの収集と照会 (Kubeletの役割)

Kubelet は各ノードの管理主導者として、コンテナの CPU およびメモリの使用量をリアルタイムで照会・収集している。内部的には cAdvisor を通じてこれらのリソース統計を抽出する。

3. メトリクス集計用アドオンの必要性 (Metrics Server)

HPA を稼働させるためには、アドオンポッドである metrics-server を別途インストールする必要がある。

• 理由: Kubelet が収集した個々のデータをクラスター全体単位で集計し、API 形式で提供する「データハブ」が必要だからである。metrics-server が未設置の場合、Controller Manager は判断材料となるデータを得ることができない。

4. スケーリングの判断と実行 (Controller Manager)

Controller Manager（内部の HPA コントローラー）は、metrics-server から提供されるメトリクス情報と、HPA 設定に定義された閾値（Threshold）を比較・検証する。

• 比較周期: Controller Manager は 15秒単位 でメトリクスをチェックし、スケーリングの必要性を検証する。
• 動作: 現在のメトリクスが設定された閾値を超過（または下回る）した場合、Controller Manager は Deployment の replicas 数を更新し、実際のポッド数を増減させるスケーリングを発生させる。

---

■動作確認

▶ Resource 確認

# kubectl api-resources

 

▶ 主要コンポーネントのログ確認

# kubectl get pods -n kube-system
# kubectl logs -n kube-system etcd-k8s-master
# kubectl logs -n kube-system kube-scheduler-k8s-master
# kubectl logs -n kube-system kube-apiserver-k8s-master
...

▶ Master Nodeファイル

// k8s証明書
# cd /etc/kubernetes
①/etc/kubernetes 配下に 「admin.conf」 という認証設定ファイルがある。
②①より、kube-apiserver への接続が可能になる。
# ls /root/.kube/config
①上記の「admin.conf」の内容を、~/.kube/configにCopyする。
②kubectlはこの認証情報を参照してAPI ServerにRequestする。
// Control Plane Component Pod生成yamlファイル
# ls /etc/kubernetes/manifests

// すべてのPodログ
/var/log/pods/<namespace_<pod-name>_<uid>/<number>.log
/var/log/containers/<pod-name>_<namespace>_<container-name>_<container-id>.log

 

▶ TroubleShooting

// kubelet状態確認
1) systemctl status kubelet       // systemctl (restart or start) kubelet
2) journalctl -u kubelet | tail -10

// 状態確認 -> 詳細なログ確認 -> 10分ほど調査 -> VM再起動 -> Cluster再構築 ->  答えが見つかるまで調査

// containerd状態確認
1) systemctl status containerd
2) journalctl -u containerd | tail -10

// Node状態確認
1) kubectl get nodes -o wide
2) kubectl describe node k8s-master

// Pod状態確認
1) kubectl get pods -A -o wide
// Event 확인 (default: 1h)
2-1) kubectl get events -A
2-2) kubectl events -n anotherclass-123 --types=Warning  (or Normal)
// Log確認
3-1) kubectl logs -n anotherclass-123 <pod-name> --tail 10    // 10行のみ照会
3-2) kubectl logs -n anotherclass-123 <pod-name> -f           // リアルタイムで照会
3-3) kubectl logs -n anotherclass-123 <pod-name> --since=1m   // 1分以内に生成されたログのみ表示

 

쿠버네티스 컴포넌트

 

▶ iptables

# iptables -t nat -L KUBE-NODEPORTS -n  | column -t