LoginSignup
64
63

More than 3 years have passed since last update.

@zembutsu(Masahito Zembutsu)inさくらインターネット株式会社

Kubernetes 1.11 カスタム・クラスタをゼロ（スクラッチ）から構築（参考訳）

Last updated at Posted at 2018-07-10

概要

Creating a Custom Cluster from Scratch - Kubernetes
https://kubernetes.io/docs/setup/scratch/

こちらにクラスタ構築やカスタマイズに関して有益と思われる情報が記載されていました。参考のために翻訳しましたので、共有いたします。日本語で熟れない表現、分かりづらいところ、変更提案がございましたらお知らせください。

カスタムクラスタをゼロから構築

このガイドが対象としているのは、カスタム Kubernetes クラスタを高度な技術でうまく作りたい方々です。こちらの一覧から、既存の導入ガイドから必要に応じたガイドを見つけられれば、そちらをお読みいただくのを推奨します。他のガイドを試されるよりも役立つでしょう。しかしながら、特定の IaaS、ネットワーク機能、設定管理、オペレーティングシステムの必要条件に一致するものが先程のガイドになければ、こちらのガイドで皆さんが必要に応じて取るべき手順概要を提供します。予め準備されているガイドをご利用になるよりも、かなりの取り組みが必要になりますのでご注意ください。

またこのガイドは、既存のクラスタをセットアップするスクリプトが何をしているか、高いレベルで手順を理解をしたい方にも役立つでしょう。

設計と準備

学習

  1. 既に Kubernetes の使用に慣れているべきでしょう。他の導入ガイドのどれか１つに従い、一時的なクラスタのセットアップを推奨します。これにより、まず CLI (kubectl) と概念（ポッド、 サービス、等 ）に慣れるのが役立つでしょう。
  2. 皆さんの PC 上に kubectl をインストールすべきでしょう。この結果、他の導入ガイドを終わらせようとしても、思わぬ副作用を引き起こすかもしれません。問題なければ こちら の手順に従ってください。

クラウド・プロバイダ（Cloud Provider）

Kubernetes にはクラウド・プロバイダ（Cloud Provider）の概念を持ちます。クラウド・プロバイダとはインターフェースを提供するモジュールであり、TCP 負荷分散、ノード（インスタンス）、ネットワーク上の径路を管理します。インターフェースは pkg/cloudprovider/cloud.go で定義されています。これはクラウド・プロバイダの実装を変更せずに、カスタム・クラスタの構築を可能にします（たとえばベアメタルを使いたい場合）。また、インターフェースが必要な全ての部品を実装する必要はありません。依存するのは、様々な構成要素（コンポーネント）でどのようにフラグをセットするかに依存します。

ノード

  • 物理または仮想マシンを使用できます。
  • クラスタは１台のマシンでも構成可能ですが、全ての例やテストを行うには、少なくとも４つのノードが必要です。
  • 多くの導入ガイドはマスタ・ノードと通常のノードを区別しています。厳密には不要です。
  • ノードには x86_64 アーキテクチャに対応した何らかの Linux バージョンが必要です。他の OS やアーキテクチャも実行可能かもしれませんが、このガイドでは扱いません。
  • apiserver と etcd は１台のマシンで一緒に動かして構いません。10台のノードで構成するクラスタごとに、マシンは１コア、1GB のメモリです。より大きなクラスタでは、さらに多くのコアを用意した方が良いでしょう。
  • 他のノードはより多くのメモリと多くのコア数が適切です。設定は全てを同じにする必要はありません。

ネットワーク

ネットワーク接続性

Kubernetes は独自のネットワーク構造（モデル）です。

Kubernetes はポッドごとに IP アドレスを割り当てます。クラスタの作成時、ポッド IP が利用するために、Kubernetes に対して IP アドレスのブロックを割り当てる必要があります。クラスタに追加するノードごとに、異なる IP のブロックを割り当てるのが一番簡単な取り組みです。

  • オーバレイ・ネットワークを使用する
    • オーバレイ・ネットワークは基礎となるネットワーク構造（アーキテクチャ）を覆い隠します。これは、ポッド・ネットワークを通した通信（トラフィック）をカプセル化（例えば vxlan）するためです。
    • どのような解決策（ソリューション）を用いても、カプセル化は性能を低下します。
  • オーバレイ・ネットワークを使用しない
    • ポッドの IP アドレスを認識できるよう、基礎となるネットワーク構成要素（fabric）（スイッチ、ルータ、等）を設定します。
    • オーバレイによるカプセル化が不要なため、より良い性能を得られます。

どの手法を選択するかは、環境と必要条件に依存します。上述のオプションを実装するには、様々な方法があります。

  • Kubernetes が呼び出すネットワーク・プラグインを使う
  • Kubernetes が直接コンパイルをサポート
    • クラウド・プロバイダ・モジュールの「Routes」（径路付け）インターフェースとして実装可能できます。。
    • Google Compute Engine (GCE) と AWS がこの方法です。
  • Kubernetes のネットワーク外で設定
    • 手動でのコマンド実行や、外部で保守されているスクリプト群を通して行います。
    • 自分自身で実装する必要がありますが、高い自由度を得られます。

Pod IP のアドレス範囲を自分で選択する必要があります。

  • 様々な取り組み：
    • GCE: 各プロジェクトが自身で 10.0.0.0/8 を持ちます。各 Kubernetes クラスタの領域から /16 が切り取られますので、複数のクラスタのために余地を残します。
    • AWS: 組織ごとに１つの VPC を使うため、クラスタが大きな塊となるか、異なるクラスタごとに異なる VPC を用います。
  • 各ノードの Pod に１つの CIDR サブネットを割り当てるか、小さな CIDR よりも大きな CIDR が自動的に各ノードに割り当てられます。
    • ノードごとの最大ポッド数（max-pods-per-node） × 最大ノード数（max-number-of-nodes）の IP アドレスが合計で必要です。マシンで 254 のポッドをサポートできるよう、ノードごとに /24が一般的な選択です。IP が不足していれば、 /26 （マシンごとに 62 ポッド）か、あるいは /27 （30ポッド）でも十分でしょう。
    • たとえば、クラスタの範囲として 10.10.0.0/16 を用いると、最大で256 ノードが 10.10.0.0/24 から 10.10.255.0/24 の範囲で個々に使えます。
    • これらには到達可能（routable）かオーバレイで接続できるようにする必要があります。

また、Kubernetes は IP を各 サービス にも割り当てます。しかしながら、サービス IP に到達可能（routable）である必要はありません。ノードから通信が離れる前に、ポッド IP に対し、kube-proxy はサービス IPの変換（translating Service IP）を管理します。サービスに対して IP のブロックを割り当てる必要があります。これを SERVICE_CLUSTER_IP_RANGE （サービス・クラスタ IP 範囲）と呼びます。たとえば SERVICE_CLUSTER_IP_RANGE="10.0.0.0/16" を指定したら、一度に 65534 の異なるサービスを動かせます。範囲の最後に到達してしまうと、既に利用しているサービスやノードを壊さず移動できませんので、ご注意ください。

また、マスタ・ノードに対しては固定 IP の選定が必要です。

  • これを MASTER_IP （マスタ IP）と呼びます。
  • apiserver のポート 80 と 443 の両方・あるいは片方に対してファイアウォールからの接続を開く（オープンにする）必要があります。
  • ipv4 転送（フォワーディング）を sysctl で有効にするには、 net.ipv4.ip_forward = 1 を実行します。

ネットワーク・ポリシー

Kubernetes は ネットワーク・ポリシー リソースを使って、きめ細かなポッド間におけるネットワーク・ポリシー定義を可能にします。

全てのネットワーク・プロバイダが Kubernetes ネットワーク・ポリシー API をサポートするわけではありません。詳しい情報はネットワーク・ポリシーの利用をご覧ください。

クラスタの命名

クラスタには名前を付けるべきでしょう。今後重複しないユニークで短い名前を各クラスタごとに選びます。いくつかの手段で使われます。

  • kubectl でアクセスが必要な様々なクラスタ間を識別します。後々になり、新しい Kubernetes リリースのテストなど、２つめのクラスタを準備したいとき、世界の別のリージョンで実行したいとき等です。
  • Kubernetes クラスタはクラウド・プロバイダのリソースを作成できますので（たとえば、AWS の ELB）、作成するリソースを区別するためにクラスタの識別が必要です。これが CLUSTER_NAME （クラスタ名）です。

ソフトウェアのバイナリ

それぞれのバイナリが必要です：

  • etcd
  • コンテナを動かすもの、どちらか１つ:
    • docker
    • rkt
  • Kubernetes
    • kubelet
    • kube-proxy
    • kube-apiserver
    • kube-controller-manager
    • kube-scheduler

Kubernetes バイナリのダウンロードと展開

Kubernetes バイナリ・リリースに含まれてるのは、Kubernetes の全てのバイナリだけでなく、サポート対象の etcd もです。Kubernetes バイナリ・リリースを使う（推奨）か、開発ドキュメント にある手順に従い Kubernetes バイナリの構築も可能です。このガイドではバイナリ・リリースを使う方法のみ扱います。

最新のバイナリ・リリースをダウンロードし、展開（unzip）します。Kubernetes 最新の tar ボールには、サーバのバイナリは含まれていません。そのため、クライアントとサーバのバイナリをダウンロードするには、./kubernetes/cluster/get-kube-binaries.sh を探して実行する必要があります。それから ./kubernetes/server/kubernetes-server-linux-amd64.tar.gz を探し、 それを 展開（unzip）します。それから、２回めに展開したファイル群の場所へ移動し、全ての必要なバイナリが含まれている ./kubernetes/server/bin を探します。

イメージの選択

コンテナのほかにも docker 、kubelet、kube-proxy を実行します。何らかのシステム・デーモンも同様に実行する必要があるため、それぞれのバイナリが必要です。etcd、kube-apiserver、kube-controller-maager、kube-scheduler については、コンテナとしての実行を推奨しますので、イメージを構築する必要があります。

Kubernetes イメージには複数の選択肢があります：

  • Google Container Registry (GCR)にあるイメージを使う：
    • たとえば、 k8s.gcr.io/hyperkube:$TAG の場合、 TAG が最新（latest）リリースのタグのものです。これは 最新恩リリースページにあります。
    • kubelet や kube-proxy で使おうとしている release タグも $TAG と同じかどうか確認します。
    • hyperkube バイナリは、すべてが１つのバイナリに入っています。
    • hyperkube kubelet ... は kubelet を実行し、 hyperkube apiserver ... は apiserver を実行します。
  • 自分でイメージを構築する：
    • プライベート・レジストリを使う場合に便利です。
    • リリースには ./kubernetes/server/bin/kube-apiserver.tar のようなファイルを含みます。こちらを docker イメージに変換するには docker load -i kube-apiserver.tar コマンドで変換できます
    • イメージの読み込みが成功したかどうかの確認は、docker images のようなコマンドを使い、リポジトリとタグが正しいかどうかご確認ください。

etcd の場合は、次のようにできます：

  • k8s.gcr.io/etcd:2.2.1 のような Google Contaienr Registry (GCR) にあるイメージを使う。
  • Docker Hub や Quay.io にある quay.io/coreos/etcd:v2.2.1 のようなイメージを使う。
  • OS ディストリビューションに含まれている etcd 倍内を使う。
  • 自分でイメージを構築する。
    • 自分でできます: cd kubernetes/cluster/images/etcd; make

私たちが推奨する etcd のバージョンは、Kubernetes バイナリ配布物で提供されているものです。Kubernetes バイナリのリリースには、広範囲にテストされた etcd のバージョンが含まれていますが、他のバージョンではありません。また、推奨されているバージョン番号は kubernetes/cluster/images/etcd/Makefile にある TAG の値からもわかります。

以降のドキュメントでは、イメージ識別子を選択し、適切な環境変数（env var）に保存しているものとみなします。例（latest タグと適切なレジストリに書き換えてください）：

  • HYPERKUBE_IMAGE=k8s.gcr.io/hyperkube:$TAG
  • ETCD_IMAGE=k8s.gcr.io/etcd:$ETCD_VERSION

セキュリティ・モデル

セキュリティに対して２つの主なオプションがあります：

  • apiserver に HTTP で接続
    • セキュリティのためにファイアウォールを使う
    • こちらはセットアップが簡単
  • apiserver に HTTPS で接続
    • https に証明書とユーザ用の信用証明書（credential）を使う
    • こちらが推奨する手法
    • 証明書の設定には注意が必要（トリッキー）

HTTPS で取り組む場合は、証明書と信用証明書を自分で準備する必要があります。

信用証明書の準備

複数の証明書を準備する必要があります：

  • マスタを HTTPS サーバとして稼働するために必要な証明書
  • kubelet がマスタのクライアントとして自身の認識と、HTTPS 経由で自身の API を提供するときは、オプションで証明書が必要

実在する認証局（CA）で証明書を作るのを計画している場合を除き、ルート証明書（root cert）を作成し、これをマスタ、kubeletl、kubectl 証明書に対する署名で用いる必要があります。この方法については 認証ドキュメントに記述しています。

最終的には以下のファイルを扱います（それぞれを後ほど使います）。

  • CA_CERT
    • apiserver を動かすノードに置きます。設置例 /srv/kubernetes/ca.crt
  • MASTER_CERT
    • CA_CERT で署名されたもの
    • apiserver を動かすノードに置きます。設置例 /srv/kubernetes/server.crt
  • MASTER_KEY
    • apiserver を動かすノードに置きます。設置例 /srv/kubernetes/server.key
  • KUBELET_CERT
    • オプション
  • KUBELET_KEY
    • オプション

証明書の準備

管理者（と何らかのユーザ）が必要です：

  • トークンまたはパスワードで識別します
  • トークンは長いアルファベット文字列であり、例えば３２文字です。こちらをご覧ください。
    • TOKEN=$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64 | tr -d "=+/[:space:]" | dd bs=32 count=1 2>/dev/null)

トークンとパスワードは apiserver が読み込めるファイルに格納する必要があります。このガイドでは /var/lib/kube-apiserver/known_tokens.csv を使います。このファイルの書式については 認証ドキュメント に詳細があります。

クライアントに証明書を配布するには、 Kubernetes では kubeconfig ファイル の中に証明書を入れるのが慣例です。

管理者は次の手順で kubeconfig ファイルを作成できます：

  • 特に調整していない Kubernetes クラスタがあれば（たとえば、導入ガイドを使う場合）、既に $HOME/.kube/config ファイルがあります。
  • kubeconfig ファイルに対して証明書、鍵、マスタ IP を追加する必要があります：
    • ファイアウォールのみ（firewall-only）セキュリティ・オプションを使う場合、apiserver は、このように設定します：
      • kubectl config set-cluster $CLUSTER_NAME --server=http://$MASTER_IP --insecure-skip-tls-verify=true
    • あるいは、apiserver IP、クライアントの証明書とユーザの信用証明書（Credential）を設定するには、このようにします：
      • kubectl config set-cluster $CLUSTER_NAME --certificate-authority=$CA_CERT --embed-certs=true --server=https://$MASTER_IP
      • kubectl config set-credentials $USER --client-certificate=$CLI_CERT --client-key=$CLI_KEY --embed-certs=true --token=$TOKEN
    • クラスタをデフォルトで使用するクラスタに指定するには：
      • kubectl config set-context $CONTEXT_NAME --cluster=$CLUSTER_NAME --user=$USER
      • kubectl config use-context $CONTEXT_NAME

次に、kubelet と kube-proxy に対応する設定ファイルを作ります。ファイルを作成するには様々な選択肢があります：

  1. 管理者向けと同じ信用証明書（credential）を書く
    • 最もセットアップが簡単です。
  2. あるトークンと kubeconfig ファイルを kubelet 向けとし、あるものは kube-proxy 用、あるものは admin （管理用）とする。
    • 現在の GCE が行っている模倣です。
  3. kubelet ごとに異なる信用証明書（credential）を使う、等
    • 対応中ですが、まだ全ての部品が揃っていません。

ファイルは $HOME/.kube/config にコピーして作成できますが、あるいは以下のテンプレートを使っても作成できます：

apiVersion: v1
kind: Config
users:
- name: kubelet
  user:
    token: ${KUBELET_TOKEN}
clusters:
- name: local
  cluster:
    certificate-authority: /srv/kubernetes/ca.crt
contexts:
- context:
    cluster: local
    user: kubelet
  name: service-account-context
current-context: service-account-context

kubeconfig を全てのノードに置きます。このガイドの後半では、/var/lib/kube-proxy/kubeconfig と /var/lib/kubelet/kubeconfig に kubeconfig ファイルがある想定です。

ノードの設定と、土台となるソフトウェアのインストール

このセクションではマシンを Kubernetes ノードに設定する方法を扱います。

  • docker または rkt
  • kubelet
  • kube-proxy

また、土台となる OS インストールに加えて、その上に様々な設定が必要になる場合があります。

Tip：開始地点（スタート地点）としては既存の導入ガイドを使ってクラスタを作る方が望ましいかもしれません。クラスタが稼働後、クラスタから init.d スクリプトや systemd ユニットファイルをコピーし、カスタム・クラスタのために変更して利用できます。

Docker

必要な Docker の最小バージョンは、Kubelet のバージョン変更に伴い変わります。最も新しい安定版（stable）リリースが良い選択です。もしも kubelet のバージョン番号が古く、警告が出てポッドの開始が拒否されるのであれば、新しいバージョンを導入してからお試しください。

もしも、以前に Docker をインストールしたものの、Kubernetes 対応オプションの設定が無かった場合は、Docker が作成したブリッジと iptables ルールがあるかもしれません。Kubernetes 対応の Docker 設定を進める前に、削除したい場合は、次のようにします。

iptables -t nat -F
ip link set docker0 down
ip link delete docker0

Docker の設定にあたっては、ネットワーク上で到達可能な vip（routable-vip）やオーバレイ・ネットワークの取り組みを、どう選ぶかに依存します。推奨される Docker のオプションは：

  • ノードごとの CIDR 範囲にブリッジを自分で作成し、その名称が cbr0 であれば、 docker で --bridge=cbr0を指定します。
  • --iptables=false を設定すると、docker はホスト・ポート（host-ports）の iptables を操作しません（docker の古いバージョンでは雑な設定したが、新しいバージョンでは修正されているかもしれません）。そのため、docker ではなく kube-proxy が iptables を管理可能になります。
  • --ip-masq=false
    • ポッド IP を到達可能（routable）にセットアップしたい場合は、こちらを false にします。そうしなければ、docker はポッド IP ソースアドレスをノード IP に｀書き換えるでしょう。
    • 環境によっては（GCE など）、クラウド環境から離れるには、アウトバウンドにトラフィックをマスカレードする必要があります。これは環境にとても依存します。
    • オーバレイ・ネットワークを使うには、これらの手順を調べます。
  • --mtu=
    • Flannel 使用時は、UDP はカプセル化によるパケットサイズが大きくなるため、必要となるかもしれません。
  • --insecure-registry $CLUSTER_SUBNET
    • SSL を使用しないプライベート・レジストリ に対して接続をしたい場合。

docker が開けるファイル数を増加したい場合：

  • DOCKER_NOFILE=1000000

この設定場所はノードの OS に依存します。たとえば、GCE の Debian を土台とするディストリビューションは /etc/default/docker を使います。

確実にシステム上で docker を正しく動かすには、この手順の後半に進む前に、Docker ドキュメントの記述を理解ください。

rkt

rkt は Docker の代わりとなるものです。Docker か rkt のどちらか一方のみインストールが必要です。必要な最小バージョンは v0.5.6 です。

ノード上で rkt を実行するには systemd が必要です。rkt v0.5.6 に対応する必要バージョンは systemd 215 です。

また、rkt ネットワーク機能のサポートには rkt メタデータ・サービス（metadata service） も必要です。rkt メタデータ・サービスを開始するには、コマンドラインで sudo systemd-run rkt metadata-service を使います。

それから、kubelet にフラグを設定する必要があります：

  • --container-runtime=rkt

kubelet

全てのノードで kubelet を実行すべきです。詳細はソフトウェアのバイナリをご覧ください。

検討する引数：

  • HTTPS セキュリティ方式に対応するには:
    • --kubeconfig=/var/lib/kubelet/kubeconfig
  • あるいは、ファイアウォールを土台とするセキュリティ方式であれば
  • --config=/etc/kubernetes/manifests
  • --cluster-dns= セットアップする DNS サーバのアドレス(クラスタ・サービスの開始 Cluster Servicesをご覧ください。)
  • --cluster-domain= クラスタ DNS アドレスが使う DNS ドメイン・プレフィックス（訳者注；先頭に付ける文字）
  • --docker-root=
  • --root-dir=
  • --pod-cidr= ポッド IP アドレスが使う CIDR であり、スタンドアロン・モードでのみ使います。クラスタ・モードでは、CIDR はマスタから取得します。
  • --register-node (ノード ドキュメントに記述があります)

kube-proxy

全てのノードで kube-proxy を実行すべきです（厳密には "master" ノード上で実行する必要はありませんが、整合性を取るのが簡単です）。バイナリの取得は kubelet に記述してあります。

検討する引数：

Linux プラットフォームによっては、 kube-proxy が依存する conntrack パッケージを手動でインストールする必要があるでしょう。もしそうでなければ、起動できません。

kube-proxy 問題のデバッグに関する詳細は サービスのデバッグ を参照ください。

ネットワーク機能

各ノードはポッド・ネットワーク用に自身の CIDR 範囲を割り当てる必要があります。これを NODE_X_POD_CIDR と呼びます。

各ノードでは cbr0 と呼ぶブリッジの作成が必要です。このブリッジの詳細は ネットワーク機能ドキュメント で説明しています。ブリッジ自身が NODE_X_POD_CIDR からの IP アドレスを必要とします。これは慣例として１つめの IP であり、 NODE_X_BRIDGE_ADDR と呼びます。たとえば、 NODE_X_POD_CIDR が 10.0.0.0/16 であれば、NODE_X_BRIDGE_ADDR は 10.0.0.1/16 です。メモ：保持している/16 サフィックスをどう扱うかは、後から使います。

もしもポッドがお互いに通信できるよう、Docker の IP マスカレード機能を無効にしている場合は、送信先 IP がクラスタ・ネットワーク外になるようマスカレーディングが必要になる場合があります。例：

iptables -t nat -A POSTROUTING ! -d ${CLUSTER_SUBNET} -m addrtype ! --dst-type LOCAL -j MASQUERADE

これはポッド IP をソースとするアドレスを、ノード IP に書き換えるもので、通信がクラスタの外に流れるようにします。また、カーネルのconnection tracking によって、到達したポッドからもノードが確実に応答できるようにします。

メモ：これは環境により異なります。ある環境ではマスカレードは不要でしょう。一方で、GCE のような所では、ポッドの IP がインターネットにトラフィックを遅れませんが、GCE プロジェクト内では何ら問題はありません。

その他

  • 必要に応じて OS パッケージ・マネージャの自動更新を有効にします。
  • 全て音ノード構成要素のログ・ローテーションを設定します（たとえば logrotate を使います）。
  • 死活監視をセットアップします（たとえば supervisord を使います）.
  • ボリューム・プラグイン・サポートをセットアップします（オプション）。
    • オプションでボリューム・タイプのクライアンド・バイナリをインストールします。GlusterFS ボリュームであれば glusterfs-client です。

構成管理を使う

これまでの手順において、マシンのセットアップに必要なのは、すべて「旧来の」システム管理技術でした。ノード設定処理を自動化するために、設定管理システムを使いたいかもしれません。様々な導入ガイドに、 Saltstack、Ansible、Juju、CoreOS Cloud Config の例があります。

クラスタの初回起動（ブートストラップ）

基本ノード・サービス（kubelet、kube-proxy、docker）は、伝統的なシステム管理手法や自動化手法を用いて、一般的に起動および管理できます。そして Kubernetes の マスタ 構成要素は、全て Kubernetes によって設定・管理されます。

  • これらのオプションは /etc/init.d ファイルや systemd unit ではなく、ポッドの spec（yaml か json）で指定します。
  • これらは init ではなく、Kubernetes によって実行を保たれます。

etcd

１つまたは複数の etcd インスタンスを実行する必要があります。

  • 可用性を高めて、簡単に復旧する - etcd インスタンスを３つまたは５つ起動し、持続的なストレージ（RAID、GCE PD）が背後にあるディレクトリにログを書き出します。
  • 可用性が高くなくても、簡単に復旧する - etcd インスタンスを１つ起動し、持続的なストレージ（RAID、GCE PD）が背後にあるディレクトリにログを書き出します。
**メモ:**インスタンスの障害によって、結果的に機能障害に至る場合があります。

  • 可用性を高める - 持続的ではないストレージに、etcd を３または５つ起動する。

    メモ: ストレージは複製されるため、持続的ではないストレージにもログを書き出します。

クラスタ可能性に影響する要素の議論は、クラスタ・トラブルシューティング をご覧ください。

etcd インスタンスを実行するには：

  1. cluster/gce/manifests/etcd.manifest をコピーします。
  2. 必要に応じて変更を加えます。
  3. kubelet マニフェスト・ディレクトリに置き、ポッドを開始します。

api サーバ、コントローラ・マネージャ、スケジューラ

api サーバ、コントロール・プレーン、スケジューラは、それぞれマスタ・ノード上のポッドとして実行されます。

これらの構成要素ごとの、起動する手順は似ています：

  1. ポッド用のテンプレートを与えて起動します。
  2. イメージの選択 で選択したイメージ名を `HYPERKUBE_IMAGE に入れます。
  3. 後述するテンプレートに関するアドバイスを用い、クラスタに応じて必要なフラグを決めます。
  4. コマンド配列（以降の例では $ARGN）でフラグを個々の文字列として設定します。
  5. 完成したテンプレートを kubelet マニフェスト・ディレクトリに置き、ポッドを起動します。
  6. ポッドの輝度を確認します。

api サーバのポッド・テンプレート

{
  "kind": "Pod",
  "apiVersion": "v1",
  "metadata": {
    "name": "kube-apiserver"
  },
  "spec": {
    "hostNetwork": true,
    "containers": [
      {
        "name": "kube-apiserver",
        "image": "${HYPERKUBE_IMAGE}",
        "command": [
          "/hyperkube",
          "apiserver",
          "$ARG1",
          "$ARG2",
          ...
          "$ARGN"
        ],
        "ports": [
          {
            "name": "https",
            "hostPort": 443,
            "containerPort": 443
          },
          {
            "name": "local",
            "hostPort": 8080,
            "containerPort": 8080
          }
        ],
        "volumeMounts": [
          {
            "name": "srvkube",
            "mountPath": "/srv/kubernetes",
            "readOnly": true
          },
          {
            "name": "etcssl",
            "mountPath": "/etc/ssl",
            "readOnly": true
          }
        ],
        "livenessProbe": {
          "httpGet": {
            "scheme": "HTTP",
            "host": "127.0.0.1",
            "port": 8080,
            "path": "/healthz"
          },
          "initialDelaySeconds": 15,
          "timeoutSeconds": 15
        }
      }
    ],
    "volumes": [
      {
        "name": "srvkube",
        "hostPath": {
          "path": "/srv/kubernetes"
        }
      },
      {
        "name": "etcssl",
        "hostPath": {
          "path": "/etc/ssl"
        }
      }
    ]
  }
}

必要に応じて api サーバのフラグを指定します：

  • --cloud-provider= クラウド・プロバイダ をご覧ください
  • --cloud-config= クラウド・プロバイダ をご覧ください
  • --address=${MASTER_IP} または --bind-address=127.0.0.1 と --address=127.0.0.1 を、マスタ・ノード上でプロキシを実行したい場合
  • --service-cluster-ip-range=$SERVICE_CLUSTER_IP_RANGE
  • --etcd-servers=http://127.0.0.1:4001
  • --tls-cert-file=/srv/kubernetes/server.cert
  • --tls-private-key-file=/srv/kubernetes/server.key
  • --enable-admission-plugins=$RECOMMENDED_LIST
  • --allow-privileged=true は、クラスタの利用者がポッドを root として実行するのが信頼できる時のみ

ファイアウォールのみのセキュリティ方式であれば、これらの引数を使います：

  • --token-auth-file=/dev/null
  • --insecure-bind-address=$MASTER_IP
  • --advertise-address=$MASTER_IP

HTTPS 方式を使う場合、こちらを指定します：

  • --client-ca-file=/srv/kubernetes/ca.crt
  • --token-auth-file=/srv/kubernetes/known_tokens.csv
  • --basic-auth-file=/srv/kubernetes/basic_auth.csv

このポッドは hostPath ボリュームを用い、複数のノード・ファイルシステム・ディレクトリをマウントます。 それらの目的は：

  • /etc/ssl のマウントで api サーバが SSL ルート証明書を見つけられるため、クラウド・プロバイダのような外部サービスを認証できます。
    • クラウド・プロバイダを使わなければ（たとえばベアメタル）、こちらは不要です。
  • /srv/kubernetes のマウントで api サーバがノード・ディスク上に保管された証明書と信用証明書（credential）を読めるようになります。これにより、GCE PD のような永続的なディスクやイメージ内に保管する代わりとなります。
  • オプションとして、 /var/log も同様にマウントし、そこに出力先を変えます（リダイレクトします）。（テンプレートにはありません）
    • ログはルート・ファイルシステムから journalctl のようなツールを使い、アクセスできるほうが好ましいでしょう。
クラウド・プロバイダ {#cloud-providers}

apiサーバは複数のクラウド・プロバイダをサポートします。

  • --cloud-provider フラグ用のオプションは aws、 azure、 cloudstack、 fake、 gce、 mesos、 openstack、 ovirt、 rackspace、 vsphere、あるいは未指定です。
  • 未指定はベアメタルのセットアップに使います。
  • こちらから コードによる貢献が追加されると、新しい IaaS がサポートされます。

いくつかのプロバイダは設定ファイルが必要です。そのため、設定ファイルを api サーバのイメージに入れるか、hostPath のマウントが必要です。

  • クラウド・プロバイダで設定ファイルが必要な場合は --cloud-config= で指定します。
    • aws、 gce、 mesos、 openstack、 ovirt、 rackspace で使います。
    • 設定ファイルは api サーバ・イメージに置くか hotPath を通してマウントする必要があります。
  • Cloud 設定ファイルの構文は Gcfg です。
    • AWS のフォーマットはタイプ AWSCloudConfig で定義されています。
    • 他のクラウド・プロバイダも類似のファイル・タイプです。

スケジューラ・ポッドのテンプレート

スケジューラ・ポッド用向けに完成したテンプレートです：

{
  "kind": "Pod",
  "apiVersion": "v1",
  "metadata": {
    "name": "kube-scheduler"
  },
  "spec": {
    "hostNetwork": true,
    "containers": [
      {
        "name": "kube-scheduler",
        "image": "$HYPERKUBE_IMAGE",
        "command": [
          "/hyperkube",
          "scheduler",
          "--master=127.0.0.1:8080",
          "$SCHEDULER_FLAG1",
          ...
          "$SCHEDULER_FLAGN"
        ],
        "livenessProbe": {
          "httpGet": {
            "scheme": "HTTP",
            "host": "127.0.0.1",
            "port": 10251,
            "path": "/healthz"
          },
          "initialDelaySeconds": 15,
          "timeoutSeconds": 15
        }
      }
    ]
  }
}

通常、スケジューラ向けには追加のフラグは不要です。

オプションで、 /var/log をマウントし、出力をそちらに変えてもよいでしょう。

コントローラ・マネージャ・テンプレート

コントローラ・マネージャ・ポッド用のテンプレートです：

{
  "kind": "Pod",
  "apiVersion": "v1",
  "metadata": {
    "name": "kube-controller-manager"
  },
  "spec": {
    "hostNetwork": true,
    "containers": [
      {
        "name": "kube-controller-manager",
        "image": "$HYPERKUBE_IMAGE",
        "command": [
          "/hyperkube",
          "controller-manager",
          "$CNTRLMNGR_FLAG1",
          ...
          "$CNTRLMNGR_FLAGN"
        ],
        "volumeMounts": [
          {
            "name": "srvkube",
            "mountPath": "/srv/kubernetes",
            "readOnly": true
          },
          {
            "name": "etcssl",
            "mountPath": "/etc/ssl",
            "readOnly": true
          }
        ],
        "livenessProbe": {
          "httpGet": {
            "scheme": "HTTP",
            "host": "127.0.0.1",
            "port": 10252,
            "path": "/healthz"
          },
          "initialDelaySeconds": 15,
          "timeoutSeconds": 15
        }
      }
    ],
    "volumes": [
      {
        "name": "srvkube",
        "hostPath": {
          "path": "/srv/kubernetes"
        }
      },
      {
        "name": "etcssl",
        "hostPath": {
          "path": "/etc/ssl"
        }
      }
    ]
  }
}

コントローラ・マネージャとして使用を検討するフラグ：

  • --cluster-cidr= はクラスタ内のポッド向けの CIDR 範囲です。
  • --allocate-node-cidrs= と、もしも --cloud-provider= を使うのであれば、クラウド・プロバイダ上のポッドに割り当てて使う CIDR を指定します。
  • --cloud-provider= と --cloud-config を api サーバの箇所と同じように記述します。
  • --service-account-private-key-file=/srv/kubernetes/server.key を サービスアカウントservice account 機能のために使います。
  • --master=127.0.0.1:8080

api サーバ、スケジューラ、コントローラ・マネージャの起動と確認≈

それぞれの完全なポッド・テンプレートを kubelet 設定ファイルのディレクトリに置きます（ kubelet の引数を --config= で設定します。通常は /etc/kubernetes/manifests です）。順番はどちらでも構いません。つまり、スケジューラとコントローラ・マネージャは api サーバが稼働するまでリトライし続けます。

ps か docker ps で各プロセスが起動しているのを確認します。たとえば、kubelet で apiserver 用のコンテナが起動しているかどうかの確認は、次のようにします。

$ sudo docker ps | grep apiserver
5783290746d5        k8s.gcr.io/kube-apiserver:e36bf367342b5a80d7467fd7611ad873            "/bin/sh -c '/usr/lo'"    10 seconds ago      Up 9 seconds                              k8s_kube-apiserver.feb145e7_kube-apiserver-kubernetes-master_default_eaebc600cf80dae59902b44225f2fc0a_225a4695

それから、api サーバに接続できるかどうか試します：

$ echo $(curl -s http://localhost:8080/healthz)
ok
$ curl -s http://localhost:8080/api
{
  "versions": [
    "v1"
  ]
}

もしも kubelet に --register-node=true オプションを選択した場合、api サーバに対して自己登録（self-registering）を開始します。kubectl get nodes コマンドの実行により、まもなく全てのノードが見えるようになります。そうでなければ、ノード・オブジェクトを手動で追加する必要があります。

クラスタ・サービスの開始

クラスタ全体のサービス（cluster-wide services）を Kubernetes クラスタ全体で揃えられます。これは「アドオン」（addons）と呼ばれており、役割は管理者ガイドの概要.をご覧ください。

各クラスタ・サービスのセットアップ時に気を付けるのは、以下の通りです：

トラブルシューティング

正しいクラスタの稼働

クラスタの開始が成功しているかどうかを確かめるために、cluster/validate-cluster.sh が cluster/kube-up.sh によって使われます。

使い方例と結果：

KUBECTL_PATH=$(which kubectl) NUM_NODES=3 KUBERNETES_PROVIDER=local cluster/validate-cluster.sh
Found 3 node(s).
NAME                    STATUS    AGE     VERSION
node1.local             Ready     1h      v1.6.9+a3d1dfa6f4335
node2.local             Ready     1h      v1.6.9+a3d1dfa6f4335
node3.local             Ready     1h      v1.6.9+a3d1dfa6f4335
Validate output:
NAME                 STATUS    MESSAGE              ERROR
controller-manager   Healthy   ok
scheduler            Healthy   ok
etcd-1               Healthy   {"health": "true"}
etcd-2               Healthy   {"health": "true"}
etcd-0               Healthy   {"health": "true"}
Cluster validation succeeded

ポッドとサービスの調査

他の導入ガイドにある "クラスタの調査" セクションを通しての実行をお試しください。GCE であればこちらです。

例を試す

この時点では、 nginx 例 のように、基本的な例を通して実行すべきでしょう。

適合試験の実行

適合試験（Conformance test）. の実行を試みましょう。何らかの問題があれば、より注意を払うべき場所のヒントが得られます。

ネットワーク機能

ノードはお互いにプライベート IP を通して接続できる必要があります。あるノードから別のノードに ping や SSH できるかどうかで確認ください。

ヘルプを得るには

トラブルに遭遇した場合は、 トラブルシューティング、kubernetes-users groupへの投稿、あるいは Slack でお訊ねください。

サポート・レベル

IaaS プロバイダ 設定管理 OS ネットワーク機能 ドキュメント 確認 サポート・レベル
any any any any docs コミュニティ (@erictune)

ソリューションすべてに対するサポート・レベル情報は Table of solutions にある表をご覧ください。

64
63
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
64
63