プログラミング初心者がアーキテクトっぽく語る

見苦しい記事も多数あるとは思いますが訂正しつつブログと共に成長していければと思います

Kubernetesの基礎

コンテナ

今のご時世はなんでもコンテナだ。そしてコンテナでサービスを提供するにはKubernetes（以下、k8s）が必要だ。

architecting.hateblo.jp

今回はk8sの概要について見ていこう。

歴史

  • Googleで前身となるBorgが開発された
  • Borgの開発者を中心にGoogleでk8sの開発が始まる
  • 2015年 Googleがv1.0をリリース
  • 同年、Cloud Native Computing Foundationが設立される

主な機能

Service discovery

  • コンテナへの自動的なアドレス割当てとDNS登録による名前解決

Storage orchestration

  • Volumeによるpersistent storageの提供

Automated rollouts / rollbacks

  • canary deploymentやrollback機能の提供

Automatic bin packing

  • Schedulerによる最適なコンテナ配置

Self healing

  • 障害が発生したコンテナの復旧

Secret / Configuration management

  • SecretとConfigMapによる環境固有のConfiguration情報の管理

Load balancing

Pod

k8sにおけるdeploymentの最小単位がPodである。Podを理解することがk8sを理解することの第一歩である。

「deploymentの最小単位とはなんぞや？」という方のためにたとえ話をするとVMwareでいうならVM、Dockerで言うならコンテナのような単位である。

Podはコンテナをカプセル化する。「Pod = コンテナ」と考えてもよい。

Podには複数のコンテナを配置するができる。しかしk8sのScale out/inはPod単位で行われるため、Podに複数のコンテナが含まれていると効率が悪い。このため1コンテナ/1 Podとするのが一般的だ。

Muti-Container Pod

あえて複数のコンテナを配置するケースとして考えられるのは他のコンテナを補助する役割を持つヘルパーコンテナを補助対象のコンテナと同じPodに配置するケースだ。

同じPod内のコンテナは同じWorker Nodeに配置される。

Pod内のコンテナは皆、同じIPアドレスを持つが、ポート番号は異なる。Pod内のコンテナ同士は「localhost:ポート番号」（もしくは「127.0.0.1:ポート番号」）で通信できる。この他に共有StorageやIPCを使って通信することも可能だ。

Pod外からコンテナへのアクセス

Podにはクラスター内でユニークなアドレスが割り当てられる。Podのポート番号とコンテナのポート番号は自動的にマッピングされ、<PodのIPアドレス>:<マップされたPodのポート番号>でコンテナへアクセスできる。

クラスタ外からコンテナへのアクセス

デフォルトの状態では外部からコンテナへアクセスすることはできない。Serviceを作成してPodと紐付けることで外部からのアクセスが可能になる。

Service

ServiceはPodが他のPodや外部と通信するためのプロキシのようなものである。

Podのアドレスは変わる可能性がある。Podのアドレスを宛先にすると安定した通信ができない。

そこでServiceが固定的なIPアドレスを保持し、そのIPアドレス宛に届いたトラフィックをPodに転送する。

Serviceには複数の種類ある。

  • ClusterIP
    • Pod間通信用。
  • NodePort
    • 簡易的な外部との接続を提供。
  • LoadBalancer
    • 商用サービスに適した外部との接続を提供。

Webサービスをインターネットに公開する場合はIngressというまた別のプロキシ機能とClusterIP Serviceを組みわせることもある。

PodとService以外のオブジェクト

本記事では紙面の都合上、k8sの設定オブジェクトの中でPodとServiceのみ取り上げた。

その他の設定オブジェクトについては下記の記事で紹介している。

architecting.hateblo.jp

ノード

k8sのノードにはMaster NodeとWorker Nodeがある。

Master Nodeはk8sのControl Planeである。

Worker Nodeはコンテナを実行するホストである。

コンポーネント

Worker Node

Worker Node上の重要なコンポーネントを以下に示す。

kubelet

  • コンテナイメージののpullとrun
  • 実行中のコンテナのHealth監視

Container Runtime Interface (CRI)

  • コンテナを管理・実行するプラットフォーム
  • Docker等

kube-proxy

  • 通信を管理・制御するプロキシ
  • ロードバランスも行う

Master Node

Master Node上の重要なコンポーネントを以下に示す。

API server (kube-apiserver)

  • APIリクエストを処理するk8sのフロントエンド

etcd

  • Key-Value型のデータベース
  • k8sの設定、状態、環境固有情報を保持する

Scheduler (kube-scheduler)

  • コンテナを配置するノードを決定する
  • 決定には負荷状況やdeployment templateなどを参考にする

Controller Manager (kube-controller-manager)

  • Auto Healingなどを行いクラスタを期待される状態に維持するプロセス
  • 下記のような様々なコントローラを制御する
    • node controller : node管理
    • replication controller : replica管理