KUBE_API_ARGSに作成したRSA鍵のパスを指定します。, --insecure-bind-address を使っているのはローカルの通信を想定しているため。 Kubernetes構築 LB構築 ★. Master を kubeadm init コマンドで初期化します。.

先日、keepalivedを用いてhaproxyを冗長化する記事を上げましたが、この高可用性ロードバランサを用いて複数マスターを持つ高可用性Kubernetestクラスタを作ってみたので、その手順を公開いたしま … Help us understand the problem. 今回は、vagrantを2つ、master, node用に用意をして構築をしました。, このページで、手順で特に指定がないものは、全てmasterサーバーで実行してください。, これらの2つを使って、コンテナ間で通信するための内部ネットワークが作られます。

こちらの設定は、ユーザーごとに作られるので、Kubernetesを操作する一般ユーザーで実行してください。, ちなみに、kubectlコマンドは設定ファイルとして~/.kube/configファイルを参照するので、kubectlコマンドを使用せず、手動で~/.kube/configを作成することもできます。, WEB系出身。現在はビッグデータの基盤構築、ETLなどがメイン。 / ちなみに、現時点の最新版のkubeadm 1.8ではMasterを冗長化したクラスタの構築自動化はまだ実現できておらずkubernetes/kubeadm #216で開発中です。 言い訳. Twitterアカウント: @kuromt_. 悩み(その1) 18 冗長化どうしよう 20. Docker(コンテナ型仮想化)と Kubernetes についての簡単な紹介 2. 先日、keepalivedを用いてhaproxyを冗長化する記事を上げましたが、この高可用性ロードバランサを用いて複数マスターを持つ高可用性Kubernetestクラスタを作ってみたので、その手順を公開いたします。, アーキテクチャはシンプルで、kubeletやkubectlのAPIリクエストを直接マスターに送るのではなく、間にhaproxyを挟むことによってマスターの冗長化を実現しています。, bbrfkrさんは、はてなブログを使っています。あなたもはてなブログをはじめてみませんか?, Powered by Hatena Blog apiserver, controller-manager, scheduler, weave, proxy, kubeletはsystemdを使っています。もしもインストールされているDockerがcgroupfsを使っている場合、それに合わせるために10-kubeadm.confの中身を, 逆に、DockerのCgroup Driverをsystemdに変更してもいいです。, v1.8からkubeletはswap領域が設定されていると起動に失敗するようになりました。, swapを無効化するか、swapがあっても無視するようにkubeletの実行オプションに, you can read useful information later efficiently. 尚、パラメータの意味は次の通りです。--apiserver-advertise-address: API Server のListen IPアドレス、通常は Master … SELinuxを無効化してkubeadm, kubelet, kubectlをインストールしています。, ドキュメントでは最後にkubeletデーモンを起動しているのですが、条件によってはトラブルが起こるため意図的に消しています。詳しくはあとで出てきます。, 続いて、以下の二つを確認して必要であればkubeletの実行オプションを定義している/etc/systemd/system/kubelet.service.d/10-kubeadm.confを変更します。, 接続するetcdクラスタを指定する、ロードバランサが動くホストのための証明書を作る二つのオプションとKubernetes v1.7.5を使うためのオプションを指定してkubeadm initを実行します。オプションの内容はあらかじめkubeadm.yamlとして用意しておきます。, apiserverのデフォルトのポート番号は6443ですが、このロードバランサは本番環境とテスト環境の両方を兼ねており、6443は本番環境用に使っているためあえて違うポートを使っています。, しばらく待つと、apiserverやschedulerなどKubernetesのMasterに必要なプロセスがPodして立ち上がり、NodeがKubernetesクラスタに参加するために必要なトークンが出力されます。このトークンはNodeを登録するときに使います。, まだMasterの機能が完成していないKubernetesクラスタにPodができる理由は、kubeletにはMasterを介さず起動するStatic Podという特別なPodをたてる機能を使っているためです。kubeletがStatic Podを作るために監視している/etc/kubernetes/manifestsディレクトリにkubeadmがapiserverやschedulerのマニフェストを作成し、kubeletがそれを検知してStatic Podとして立ち上げます。, 続いて、生成されたadmin.confをkubectlの設定ファイルの置き場所にコピーしてkubectlを実行可能にします。, 最後に、Kubernetesの仮想ネットワークを作ります。ここではWeave Netを使っています。, Masterに必要な設定は1つめのMasterでkubeadm initを実行したときに完了しています。あとは、それらの設定を残りのMasterで共有すればいいだけです。, server2, server3でkubeletを動かし、server1で作られたStatic Pod用のマニフェストと証明書をコピーすることで3つのMasterの状態をそろえることにします。, 一点注意が必要なのは、コピー前にserver1のapiserverのマニフェストである/etc/kubernetes/manifests/kube-apiserver.yaml中の--admission-controlオプションから「NodeRestriction」を削除することです。kubeletはマニフェストが書き換えられたことを検知して自動的にapiserverのコンテナを再起動します。, apiserverはいくつかのセキュリティポリシーを持っているのですが「NodeRestriction」はそのNodeの設定を変更できるのはそのNodeの操作権限を持つユーザだけというポリシーです。kubeadm initはserver1の操作権限を持つユーザを作ってくれてはいますが、server2, server3の操作権限を持つユーザを作ってくれていません。権限を含めて同じMasterを作る上でこのポリシーは邪魔になります。, その後、server1の/etc/kubernetesディレクトリ一式をserver2, server3にコピーします。, 仮想ネットワークを動かすためのWeave Netは/etc/kubernetes/manifestsに含まれていませんが、全てのサーバで動くDaemonSetsとして実行されているため自動的にserver2, server3でも立ち上がります。, kubadm initを実行したときに最後に出力されたとおりに叩きます。Nodeからはロードバランサが動いているホストがKubernetesのMasterにみえます。, server5にkubectlの設定ファイルの置き場所を作り、server1からcontextsを含むadmin.confをコピーします。, Masterを一台シャットダウンしても新しいコンテナを作ることができるか確認します。ここではserver3をダウンさせましょう。, ここで、何らかのモニタリングによってserver3が死んだとアラートがあがったとします。障害対応としてKubernetesクラスタからserver3を削除します。, 次に、Masterが1台ダウンしてもクライアントからNginxのDeploymentを作れることを確認します。, ということで、Masterが故障しても新しいDeploymentsを作ることができました。, Hadoop関連とDocker、Kubernetes関連を中心に活動