はじめに
第1章 kubeadmの基礎
第2章 kubeadmの使い方
第3章 kubeadm init
第4章 kubeadm join
第5章 kubeadm reset
第6章 kubeadm upgrade
第7章 kubeadm config/token/version
第8章 kubeadm alpha
あとがき
「解体kubeadm フェーズから読み解くKubernetesクラスタ構築ツールの全貌」をお手にとっていただきありがとうございます。本書はKubernetesの管理ツールkubeadm(キューブエーディーエム/クベアダム)について解説する本です。特に、kubeadmの処理の単位であるphase(フェーズ)の内部実装について調査した結果をまとめています。kubeadmの主要な機能であるinitやjoinなどは内部では複数のphaseと呼ばれる処理のまとまりが実行されています。通常、Kubernetesやkubeadmを利用する上で、それらのphaseを意識する必要はありません。そこをあえて、phaseごとにkubeadmが一体何をしているのかを明らかにするのが本書の目的です。
Kubernetesは公式のドキュメントが充実しており、kubeadmもその例には漏れません。通常、kubeadmをただ使うだけであれば、公式ドキュメントの内容で十分な知識が得られることでしょう。ある程度詳細な仕様や説明も公式ドキュメントにはありますが、本書はその副読本となるよう、phaseという観点でソースコードも読みながら、わかりやすくなるようまとめました。kubeadmとそのphaseを理解することは、Kubernetesそのものを理解することにも繋がります。Kubernetesを解説する書籍や文献はすでに世の中に多く存在していますが、それらとはまた一風違うkubeadmという視点からKubernetesを理解できるでしょう。たとえば、有名な「Kubernetes The Hard Way」を通じて手動でKubernetesのコンポーネントを動かすことによって、Kubernetesの理解を高めた方もいるでしょう。kubeadmの処理を理解することは「Kubernetes The Hard Way」のような視点からKubernetesを理解することと近いものがあります。
多くの場合、Kubernetesクラスタを本番サービスで運用するときは、実際にはクラウドなどのマネージドKubernetesサービスを使うことになるでしょう。マネージドKubernetesサービスを使えば、そもそもkubeadmのようなツールを使う必要もなく、より簡単かつ安全にKubernetesクラスタを運用できます。マネージドKubernetesサービスが、kubeadmやそれ以上の処理をより使いやすくユーザーに提供してくれているからです。それでも、マネージドKubernetesサービスが裏側でやってくれているであろうことを理解する上でも、本書は役に立つことでしょう。本番サービスが稼働しているKubernetesクラスタで何らかのトラブルがあったとき、その裏側の仕組みを理解していると、調査や対応に大いに役立つと考えられます。ちなみに、筆者はパブリッククラウドであるニフクラのマネージドKubernetesサービス「ニフクラ Hatoba」の開発も担当しています。本書を執筆したのも、マネージドKubernetesサービスを開発する上でよりKubernetesを理解するために必要だったという経緯があります。
Kubernetesを構築・運用するためのツールはkubeadmの他にも多くのものが存在しています。そして、それらの内部実装としてkubeadmを利用しているものも数多くあります。たとえば、Cluster API、kind、minikube、kubesprayなどの有名なツールは、内部的にはkubeadmを使っているものがあります。kubeadmはKubernetes公式のツールとして構築のベストプラクティスを拡張可能な形で提供し、さらに高機能な仕組みが必要になった場合は周辺のツールで補われることを想定されています。つまり、kubeadm自体を理解するということは、内部的にkubeadmを利用しているツールの理解にも繋がります。もしくは、あなたが今までにない新たなKubenetesのツールを作ろうと思ったとき、内部的に一部の処理をkubeadmに任せることで、実現したいツールをより早く高品質に実現できるかもしれません。
ところで、本書はもともと「Phases of kubeadm」または「Phases of kubeadm 2nd Edition」という名前で技術書同人誌として技術書同人誌博覧会や技術書典で頒布していたものです。今回、株式会社インプレスR&Dさんからお話をいただき、「技術の泉シリーズ」としてより内容を強化し「解体kubeadm フェーズから読み解くKubernetesクラスタ構築ツールの全貌」と名前を変えて商業誌として出版させていただく運びとなりました。本書が商業誌として出版されることで、より多くの方々の助けになれば幸いです。
同人誌版である「Phases of kubeadm」または「Phases of kubeadm 2nd Edition」からの主な変更点として、下記が挙げられます。
・kubeadm alphaの解説追加
・Kubernetes v1.18対応
・よりわかりやすくなるよう補足説明の追加・修正
同人誌版ではv1.15やv1.16の対応となっていましたが、今回 v1.18対応するにあたり、すべての実行例を取得しなおしました。ただし、kubeadmのv1.15〜v1.18の変化は細かいバグ修正を除くとそこまで大きなものはありません。そのため、バージョン変化による解説内容の変化は些細なものになっています。どちらかというと同人誌版との変更点としては補足説明の追加・修正による差分が文量的にも多くなっています。
本書で取り扱うKubernetesのバージョンは、執筆時点での最新である v1.18.3 を利用しています。また、執筆時点で判明しているv1.19以降で対応予定の内容にも一部触れています。
本書はLinuxおよびKubernetesの入門的な知識を既に持っている方を前提として記述します。もし、まだKubernetesについて何も知らない方であれば、本書の前に公式のチュートリアル等に触れておくことをおすすめします。また、Kubernetesの基本的なコンポーネントについて知識があるとより理解しやすいでしょう。
第1章では「kubeadmの基礎」として、kubeadmの基本的な構成要素や、kubeadmが実現するKubernetes構成について解説します。第2章では「kubeadmの使い方」として、kubeadmを利用したKubernetesクラスタの作成とアップグレード方法など、基本的な使い方について解説します。すでにkubeadmを使ったことがあるという方であれば、1章および2章は読み飛ばしてもよいでしょう。
第3章以降が本書のメインコンテンツになります。kubeadmの各phaseに対して、それぞれが行っている処理の内容を解説します。3章以降は、どこからでも読んでも良いように記載しています。順番に読んでも良いですし、詳しく知りたいphaseをピックアップして読んでも良いでしょう。
表紙イラストは、株式会社インプレスR&Dさん経由でご紹介いただいた錆缶さんに描いていただきました。もともと、同人誌版でのタイトルである「Phases of kubeadm」は「Phases of moon(月の満ち欠け)」をイメージしたタイトルでした。そのため、今回はイラストの要素として月と、あとはKubernetesの海洋のイメージを入れてもらいました。ただの個人的な解釈ですが、月明かりの暗い中ばらばらに積み上げられた巨大なコンテナというものに立ち向かおうとするエンジニアの決意のようなものを感じさせられます。本書のイメージにピッタリな、とても素敵なイラストに仕上げていただけたと思います。この場を借りて感謝申し上げます。
本書では、基本的に公式のKubernetesやkubeadmで用いられている用語に従います。通常あまり馴染みのない用語も出てくるため、下記に整理します。また、Kubernetes界隈の中でも同じ用語で文脈によって表記や意味合いが多少異なる場合もありますが、本書内では下記の通り定めます。
コントロールプレーン
Kubernetesクラスタを管理するプロセス群やその役割を指します。本書やkubeadmの文脈では、単にコントロールプレーンと表記したとき、kube-apiserver、kube-scheduler、kube-controller-manager の3つのコンポーネントのみを指します。一般的なKubernetesの文脈によってはetcdやCCM、kubelet 等を含む場合がありますが、本書内では別物として扱います。多くの場合、コントロールプレーンはコンテナで稼働しますが、コントロールプレーンがコンテナであることは必須要件ではありません。kubeadmで構築した場合は、コントロールプレーンはすべてコンテナで稼働します。コントロールプレーンは、マスターコンポーネントともほぼ同義です。
マシン
Kubernetesを構成するサーバーマシンを意味します。物理的なマシンかもしれませんし、VMかもしれません。文献によってはマシンはしばしば単にノードとも表記されることがあります。本書ではマシン、ノード、マスターノードを明確に区別します。本書でマシンと表記したとき、それはノードまたはマスターノードのことを意味します。
ノード
マシンのうち、アプリケーションコンテナを動作させる役割のものをノードと表記します。文献によってはワーカーノードと表記されることもあります。
マスターノード
マシンのうち、コントロールプレーンを動作させる役割のものをマスターノードと表記します。kubeadmによってKubernetesクラスタを構築した場合、マスターノードはノードとしても機能します。単一のマシン内にアプリケーションコンテナとコントロールプレーンを混在させることも可能ですが、一般的には別のマシンで稼働させることが推奨されています。
Static Pod
Kubernetesクラスタ上では管理されない特殊なPodです。Static Podはマシン内に配置されたmanifestをもとにkubeletが直接管理します。通常のPodはKubernetes APIで操作が可能ですが、Static Podはmanifestで管理されているためKubernetes APIからは設定を操作することができません。kubeadmではコントロールプレーンおよびetcd(外部etcdを使わない場合)がStatic Podとして起動します。
kubeconfig
kubeconfigはkube-apiserver(Kubernetes API)と接続するための設定ファイルを指します。たとえば、kubectlはデフォルトで$HOME/.kubeに存在するkubeconfigを探してkube-apiserverと通信します。kubeconfigには認証方式によっても様々な設定方法があります。kubeadmで扱われるkubeconfigはクライアント証明書を使ったものになっており、kube-apiserverへ接続するためのクライアント証明書と秘密鍵およびkube-apiserverのCA証明書、エンドポイントに関する情報などが詰められています。
API Aggregation
Kubernetesを拡張する仕組みのひとつです。通常はKubernetesのリソースはkube-apiserverによって管理されますが、API Aggregationではkube-apiserverとは別のExtention APIを用意し、Extention APIで独自のリソース管理を行います。リソースに関する処理がExtention APIの管理になるため、他の拡張方式であるAdmission WebhookやCRDよりも非常に柔軟性の高いリソース管理が可能になります。ただし、その柔軟性に反してExtention APIを構築するハードルは高く、ほとんどのケースではCRDでもまかなえるため、API Aggregationはあまり使われることはないかもしれません。