Oracle Cloud Hangout Cafe Season7 #1「Kubnernetes 超入門」(2023年6月7日開催)

Kubernetesコンポーネント

ここからは、Kubernetesの各コンポーネントを見ていきます。

※概要説明となりますので、詳細はオフィシャルドキュメント「Control Plane & Node Official Documentation」を参照してください。

Control Plane & Node

Kubernetesには、大きな構成要素としてControl PlaneとNodeがあります。Control PlaneはKubernetesクラスタの「頭脳」にあたります。クラスタの状態を監視してリソースを管理し、クラスタ全体を制御します。以下のコンポーネントがあります。

• kube-apiserver
• kube-scheduler
• kube-controller-manager
• cloud-controller-manager
• etcd

Nodeは、アプリケーションコンテナが実際に稼働する場所です。以下のコンポーネントがあります。

• kube-proxy
• kubelet
• container runtime

最初に、Control Planeの各コンポーネントを見ていきます。

次に、Nodeの各コンポーネントを見ていきます。

Pod

Kubernetesは、コンテナをPodという単位で管理します。Podの主な特性は以下です。

• 1つまたは複数のコンテナをデプロイする最小単位
• Pod内のコンテナは同じホスト名とIPアドレスを持つ
• Pod内のコンテナは同じポート番号を持つことはできない
• Pod内のコンテナはローカルホスト通信
• Pod内のコンテナは同じNode上で稼働、Nodeをまたぐことはできない

下図は、Podが作成されるまでの各コンポーネントの役割です。

ReplicaSet & Deployment

ReplicaSet
ReplicaSetはPodのレプリカを作成して、マニフェストファイルで定義されたレプリカ数(replicas)を保証し、定義された数のPodを常に起動させる仕組みです。

ReplicaSetはNodeやPodに障害が発生した場合、定義されたレプリカ数を保証するために別ノードで復旧、Kubernetesのセルフヒーリング機能を担います。

【ReplicaSet Official Documentation】

Deployment
DeploymentはReplicaSetの作成、更新、履歴管理、ローリングアップデート、ロールバックなどを行います。

【Deployment Official Documentation】

下図は、Deployment、ReplicaSet、Podの関係性を表したものです。PodをReplicaSetが管理して、DeploymentがReplicaSetを管理します。

次に、セルフヒーリングの仕組みを見ていきます。下図は、セルフヒーリング時の各コンポーネントの動きです。

Kubernetesは、マニフェストの内容をあるべき理想の形(Desired State)として常にその状態であるかを監視し、相違がある場合はReconciliation Loop(調整ループ)により自動修復します。

Reconciliation Loop(調整ループ)は、Controller内で実行されている理想とするあるべき姿に収束させるループ機能です。

Reconciliation Loopの例を見ていきます。3個のNginxコンテナ(Pod)を起動することを理想とします。

2個のコンテナ(Pod)しか起動していない場合の例は下図のようになります。

【Diff】1個のコンテナ(Pod)が足りない

【Act】1個のnginxのコンテナ(Pod)を作成する

このように、Reconciliation Loop(調整ループ)により、Kubernetesでは自律的にマニフェストの定義に収束するように調整します。

Service

Serviceは、クラスタ内外からのリクエストをPodにアクセスするためのルーティングやDNS機能を提供します。以下が主な機能です。

• ClusterIP
• NodePort
• LoadBalancer

【Service Official Documentation】

ClusterIP
ClusterIPは、Kubernetesにおける内部通信用のサービスタイプです。クラスタ内のアプリケーション間で通信できます。

NodePort
NodePortはNodeのIPアドレスに公開ポート番号を開放して、クラスタ外部からのアクセスを受け付けます。Service はkube-proxyと連携して各ノードにポートを開き、ノード横断でPodにリクエストを送信します。

LoadBalancer
クラスタ外のロードバランサと連携して外部からのアクセスを受け付けます。クラウドプロバイダーが管理するクラウドリソースと連携して、外部ロードバランサーを自動的にプロビジョニングします。

Ingress

Ingressは外部からのHTTP(S)トラフィックを内部Serviceにルーティングして、レイヤ7のロードバランシングを提供します。また、パスベースルーティング、SSL/TLS終端、名前ベースのバーチャルホスティングなども実装しています。

【Ingress Official Documentation】

Volume & PersistentVolume & PersistentVolumeClaim

Volume
Volumeはコンテナ側からマウント可能なボリューム領域で、保存領域の実態をポイントします。あらかじめ用意された利用可能なVolumeをPodのマニフェストファイルから直接指定して利用できます。

【Volumes Official Documentation】

PersistentVolume & PersistentVolumeClaim
PersistentVolumeは、永続ボリュームと連携してKubernetesクラスタにボリュームを登録するリソースです。

PersistentVolumeClaimは、PersistentVolumeをアサインするリソースです。PodからPersistentVolumeを利用する場合、PodのマニフェストにPersistentVolumeClaimを定義して利用します。

下図は、PersistentVolumeとPersistentVolumeClaim利用手順の一例です。

【PersistentVolumes & PersistentVolumeClaims Official Documentation】

ConfigMap & Secret

ConfigMap
ConfigMapは環境変数、引数等の設定情報(Key-Value保持)をコンテナに渡すために使用します。Volumeとしてコンテナにマウントし、コンテナからはファイルとして認識できます。

【ConfigMaps Official Documentation】

Secret
Secretは、機密性の高いデータ(ID/Password情報、SSL/TLS証明書、アクセストークン等)を保持する上で使用するVolumeです。

Secretはbase64でエンコードされていますが、暗号化はされていません。GitリポジトリにSecretの設定が定義されているマニフェストファイルをアップロードするのはセキュリティリスクがあるため、マニフェストファイルを暗号化するオープンソースソフトウェアやベンダーのサービス、プロダクトを利用します。以下はオープンソースソフトウェアです。

• Kubesec
• SealedSecret
• ExternalSecret

【Secrets Official Documentation】

Label & Namespace

Label & Label Selector
LabelとSelectorは、Kubernetes上のオブジェクトにタグのような属性を設定してグループ化したり、特定のオブジェクトを抽出できるようにする仕組みです。

LabelはKey/Valueペアの文字列で、Podなどのオブジェクトに任意のメタ情報を付与して識別用途として利用できます。Label Selector は、Label設定値の条件に該当するものをグループとして識別用途で利用できます。

【Labels and Selectors Official Documentation】

Namespace
Namespaceは、複数のユーザ間で(リソース割り当てを介して)クラスタリソースを分割する仕組みです。Namespace の主な特性は以下です。

• 1ユーザーに1個のNamespace
• Namespaceにおけるリソース名はNamespace内で一意である必要があり、Namespace間では一意である必要はない
• Namespace毎にリソースの利用上限を設定可能

【Namespaces Official Documentation】