grasys blog

非マネージドkubernetesを味わおう

はじめまして、grasysの中村です。
今回は、最近クラウドサービスであるGKE, AKS, EKSを中心に使用しているみなさんに向けて、
原点回帰して
アンマネージド(非マネージド)Kubernetesについてお話ししたいと思います。

実はクラウドサービスではこんなことをやっていたんだ、
クラスターの中にnodeがあり、その中にpodがあるといった認識をされている方も多いかと思います。そこで、普段ブラックボックス化しがちなKubernetesの構造を紐解いてみたいと思います。

下記はイメージ画像

上記の画像から使用しているコンポーネントについてまとめたのが下記となります。

コントロールプレーン(※クラウドだと操作不可)

コンポーネント名概要
kube-apiserver心臓・全てのコンポーネントとやりとり
etcdバックアップ保管場所
kube-schedulerpodをどのnodeに配置するか決めてくれる指揮官
kube-controller-managerバランサー、理想の状態を維持してくれる

ノードエージェント

コンポーネント名概要
kubelet監視者
kube-proxyネットワークバランサー
コンテナランタイムコンテナ本体

アドオン

コンポーネント名概要
CNIネットワーク層
coreDNSIPアドレスではなく、名前解決を行うための仕組み
Dashboard管理画面
Metrics Serverkubectl topの結果元、HPA設定時のデータ元
Cluster-level Loggingコンテナログの保管先
cloud-controller-managerクラウドプロバイダー固有のコントローラー。Kubernetes環境とクラウド環境を連携させる。
※v1.27以降コントロールプレーンから移行済み。

クラウド管理のコンポーネント

上記のコントロールプレーン全般はクラウド側が管理しております。
そのため、コントロールプレーンの設定には触れませんが、自動で作成されておりコントロールプレーンの費用として管理費という料金が発生しています。

また、他の設定も特に設定変更はできません。
基本的にクラウドの場合、自由度が低いため3大クラウド全体それぞれ設定できる部分に多少の差分はありますが、ほぼ設定できないのが主になります。

ただ、非マネージドのクラウドを設定するにはまずどれが何か?という事を理解する必要があるので、まずはこちらを説明させていただきます。

kubernetesのコンポーネントについて

非マネージドのkubernetesを理解するにはまずコンポーネントがどのような役割をしているのか理解する必要があるのでこちらを書かせていただきます。

  • kube-apiserver
    全てのコンポーネントとやりとりします。kubectlコマンドなどを叩いた時に応答するのがこちらです。
  • etcd
    バックアップ保管場所であり、キーバリュー形式で保存されています。etcdがある事で、アップデートした時などにリストアすることができます。
  • kube-scheduler
    podをどのnodeに配置するか決めてくれるものです。どのノードで動かすべきなのか?を判断して自動で配置してくれています
  • kube-controller-manager
    バランサー、理想の状態を維持してくれています。例えば、特定のnodeがダウンした場合、同時にpodもダウンします。その際に、代わりのpodを起動してくれます。
  • kubelet
    ノード上の監視者。コンテナがpodの中で実際に動いているのか?というのをみてくれています。
  • kube-proxy
    ネットワークバランサーです。ノードの外部からのアクセスを適切なコンテナに転送してくれるため、podとの通信ができています。
  • コンテナランタイム
    コンテナ本体です。ツールを触ったことがあるのであれば、dockerが一番有名かもしれません。ただ、現在はcontainerdが動いているのが主流になります。
  • アドオン
    CNI
    ネットワーク層です。podが新しく作られた時にIPアドレスが割り振られると思いますが、そちらを担当します。また、CNIは公式で提供しているものがなく「通信の仕組み」は外部のプラグインです。
    そのため規格があるのですが、そちらが
    すべての Pod は、NAT(アドレス変換)なしで他のすべての Pod と通信できること。
    すべてのノードは、NAT なしですべての Pod と通信できること。
    Pod が自分自身を認識する IP アドレスは、他者がその Pod を認識する IP アドレスと同じであること。
    とのことです。
    代表的なのはCalicoやFlanelなどかと思います。
    ちなみにクラウドの場合はデフォルトの設定だとそのクラウドのオリジナルのCNIを使用しています。
  • coreDNS
    IPアドレスで指定する事ではなくpod名などの名称でやりとりするために必須なコンポーネントです。
  • Dashboard
    公式が提供しているプラウザでクラスターの状態を管理/操作できるWeb UIです。
  • Metrics Server
    各ノードやPodのCPU・メモリ使用率を収集しています。kubectl topの結果元であったり、HPA設定時の判断材料になったりしています
  • cloud-controller-manager
    クラウドプロバイダー固有のコントローラーです。Kubernetes環境とクラウド環境を連携させています。
    例えば、NodeとVMやロードバランサとServiceのType: LoadBalancerなどです。
    もともとコントロールプレーンに入っていましたが、v1.27以降コントロールプレーンから移行しています。

さいごに

つらつらと書かせていただきましたが、kubernetesのインフラ側の説明は以上になります。
ただ、上記に記載した通りコンポーネントや設定項目は無数に存在します。
かつてはこれらを一つひとつ手動で設定する非常にハードルの高い作業でしたが、現在ではベストプラクティスが定型化されています。
そのため、マネージドサービスに頼らなくても、手軽に非マネージドのKubernetes環境を構築できる便利なツールが広く普及しています。次回は、そうした環境構築ツールについてご紹介させていただこうと思います。

ありがとうございました。


採用情報
お問い合わせ