#はじめに
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の内容に準じて進めていきます。。。）
