はじめに
30代未経験からエンジニアを目指して勉強中のYNと申します。
インフラ初学者の私ですが、Kubernetes the hard wayを進めるにあたって、インフラに関する基本的な知識を体系的に学ぶことができました。
そこで、初学者目線での学びなどを本記事にまとめておきたいと思います。
目次
全体像を理解する
LAN構成
Vagrant
を用いてオンプレ環境に5台のubuntuインスタンスを起動します。
ubuntuインスタンスとLANの構成は下記のようになっています。
クラスターコンポーネントの構成
API-server
やkubelet
などのkube-system
コンポーネントはPod
を使うのが一般的ですが、今回はsystemdのservice
として書くノードに配置します。一方で、core-DNS
やWeave
などのアドオンはPod
として配置します。
masterノードが2つあるため、それぞれのAPI-server
へのアクセスはHA-proxy
でロードバランスします。etcd
も2つありますが、クラスタリングして片方をread replica的に振舞わせることで冗長化を行います。また、scheduler
とcontroller-manager
については片方のみをリーダーとして稼働させています。
(※Pod
でなくsystemd
で稼働させているため、本当にリーダーだけが動いているかは未確認です。。。)
一方で、workerノードについては、Pod
の名前解決のためにcore-DNS
を、CNIとしてはWeave
のプラグインを使用しているため、両者ともPod
として稼働しています。
これがベストプラクティスかと問われればそうでも無い気がしますが、githubの内容に準じて進めていきます。Kubernetesのクラスタのmaster冗長化のためのベストプラクティスについてはこちらを参照ください。
外部からPodへのアクセス
アプリケーションの利用者目線で上記のクラスター図を眺めると、Pod
へのアクセス方法は下記のようになります。
どちらかのworkerノードのIPアドレスのNodePort
に対してアクセスすることで、どちらかのworkerノードにあるPod
へアクセスします。
ここで注目すべきは、worker-1 / worker-2のどちらにアクセスしたとしても、どちらのPodにアクセスするかは分からないということです。
これは、Weave
がノードを跨ぐネットワークを構築し、kube-proxy
がどのpodに振り分けるか決定し、core-DNS
でpodのIPアドレスを解決する、という連携で成り立っています。
上記ネットワークについては、下記記事が分かりやすかったです。
コンポーネント間の連携
コンポーネントの連携について、今回構築するクラスターの最終形を下図にしてみました。
(※scheduler
とcontroller-manager
が、なぜLBではなくlocalhost
宛に通信しているのかよく分かりませんが、githubの内容に準じて進めていきます。。。)