Kubernetesのコンポーネントとアーキテクチャ




Kubernetesはコンテナのオーケストレーションツールとしてメインストリームの技術になっています。

 

Kubernetesの中身がどうやって作られているのか把握せずとも簡単に使用できますが、理解していると正しく使えるのでざっくり解説していきたいと思います。

 

本記事の内容
  • Kubernetesのマスターノードを構成する要素
  • Kubernetesのノードを構成する要素

 

Kubernetesは下記7つのコンポーネントから構成されています。これらのコンポーネントは全てOSSで開発されているので中身を確認することができます。

  • etcd
  • kube-apiserver
  • kube-scheduler
  • kube-controller-manager
  • kubelet
  • kube-proxy
  • kube-dns

 

それぞれ見ていきます。

Kubernetesのマスターノードを構成する要素

まずはKubernetesのマスタノード上で稼働するコンポーネントについてです。

etcd

etcdは分散KVSでKubernetesで構築するPodなど全ての構築情報を保存するデータストアです。etcdはクラスタ構成を組むことで冗長化できます。etcdはリーダーが死んでも自動でフェイルオーバーすることができます。

 

etcdのGitHubはこちら

 

kube-apiserver

Kubernetesの操作は全てkube-apiserverを通して行われます。DeploymentやServiceを作成したり、セルフヒーリングで自動でPodの数を調整するときもkube-apiserverを経由して操作が行われます。

 

このあと紹介するkube-scheduler、kubeletもkube-apiserverを使ってリソースの管理・構築を行なっています。

 

kube-apiserverは多くのリクエストを受けることになるのでLoadBalancer配下に複数台並べることで負荷分散と冗長化を行います。

kube-apiseverのGitHubはこちら

 

kube-scheduler

kube-schedulerは新規作成されたノードに未割り当てなPodを適切なノードに割り当てる処理を行います。割り当てたノード情報はkube-apiserver経由でetcdに書き込まれます。

 

kube-schedulerがノードを選択するときの判断基準としているものにPredicateとPriorityがあります。PreidicateはPodを構築するのに適切なノードか確認し、PriorityはPodがノードやゾーンに対して分散しているかチェックします。

kube-schedulerのGitHubはこちら

 

kube-controller-manager

KubernetesではDeploymentやReplicaSet、StatefullSetsなどのリソース作成を管理するものをコントローラーと言います。kube-controller-managerはこれらのコントローラーを実行するコンポーネントです。

 

各コントローラーは常にリソースの監視を行い、etcdに保存されている状態と差異がないかチェックします。差異がある場合は同じになるように操作を行います。

 

これがKubernetesのセルフヒーリングの機能です。

kube-controller-managerのGitHubはこちら

kube-dns

kube-dnsはKubernetesクラスタ内の名前解決やサービスディスカバリの役割を担っています。例えばsample-serviceというServiceへPodから通信する場合、sample-service.default.svc.cluster.localで接続することができるようになります。

 

最近、kube-dnsの後継としてCNCFにホストされているCoreDNS登場しました。CoreDNSはGoで実装された単一のバイナリで動作するDNSサーバです。Kubenetesのv1.11からDNSアドオンとしてGAになっています、

 

kube-dnsのGitHubはこちら

Kubernetesのノードを構成する要素

Kubernetesのノードで稼働するコンポーネントはkubeletとkube-proxyだけです。それぞれについて見ていきます。

kubelet

kubeletは各ノードで実行されるエージェントで、Podの起動や停止などを管理します。

 

例えば、kube-schedulerによってノードに割り当てられたPodがあるとkube-letはそれを検知して自身のノードに起動すべきコンテナを起動します。kubeletは自ノードに起動すべきコンテナ情報をkube-apiserver経由でetcdから取得します。

 

また、kube-letで扱えるコンテナランタイムには下記があります。

  • docker-shim(Docker)
  • containerd
  • cri-o
  • Frakti
  • rktlet

kube-proxy

kube-proxyは各ノードで稼働しているコンポーネントです。Serviceリソースが作られるとClusterIPやNodePort宛のトラフィックがPodに正常に転送されるようにします。転送方式は下記3つです。

  • ユーザスペースで処理(usersoaceモード)
  • iptablesで処理(iptablesモード)
  • IPVSで処理(ipvsモード)

 

userspaceモードはカーネルで処理を行わないため、カーネルで処理を行うiptablesの方が高い性能を出すことができます。しかし、iptablesはロードバランシングを行う用途がメインではないためスケールした際のパフォーマンス低下に問題があります。

 

IPVS(IP Virtual Server)はiptablesよりも性能の向上が期待されていて、ロードバランシングのアルゴリズムもラウンドロビン以外に最小接続(least conenction)や送信元IPアドレスに基づく分散(source hashing)などを利用できるようになります。Kubernetesのv1.11からIPVSがGAとなりました。

 

The following two tabs change content below.

髙妻智一

2013年CyberAgent新卒入社 スマホゲームを作る子会社に所属し、サーバーサイドのエンジニアを担当。2年目の終わりから新規子会社の立ち上げに参加し、サーバーサイドのエンジニアリーダーとしてサービースのリリースから運用までを担当。 2018年仮想通貨のスマホウォレットを提供するGinco Incにブロックチェーンエンジニアとして入社。






よく読まれている関連記事はこちら



コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です