CoreOSクラスター上にKubernetesをインストールおよび構成する方法

前書き

Kubernetesは、クラスター環境全体のDockerコンテナー内に構築されたアプリケーションを管理するために設計されたシステムです。展開とスケーリングを含む、コンテナ化されたアプリケーションのライフサイクル全体を処理します。

このガイドでは、CoreOSクラスターでKubernetesを開始する方法を示します。このシステムにより、関連するサービスをグループ化して、Kubernetesが「ポッド」と呼ぶものを使用して、単一のホスト上にユニットとして展開できます。また、ヘルスチェック機能、高可用性、およびリソースの効率的な使用も提供します。

このチュートリアルは、Kubernetes v0.7.0でテストされました。このソフトウェアは頻繁に変更されることに注意してください。バージョンを確認するには、インストール後、次を実行します：

kubecfg -version

前提条件と目標

以前のCoreOSガイドで使用したのと同じ基本的なCoreOSクラスターから始めます。この3つのメンバークラスターを稼働させるには、https：//www.digitalocean.com/community/tutorials/how-to-set-up-a-coreos-cluster-on-digitalocean [CoreOSクラスタリングガイド]に従ってください。

これにより、3つのサーバーを構成できます。各ノードは基本的にCoreOSレベルで交換可能ですが、Kubernetes内では、より専門的な役割を割り当てる必要があります。マスターとして機能する1つのノードが必要です。これにより、APIサーバーやコントローラーマネージャーなどのいくつかの追加サービスが実行されます。

このガイドでは、次の詳細を使用します。

Hostname	Public IPv4	Private IPv4	Role
coreos-1	192.168.2.1	10.120.0.1	Master
coreos-2	192.168.2.2	10.120.0.2	Minion1
coreos-3	192.168.2.3	10.120.0.3	Minion2

以下の構成では、マスターは作業を完了することができる完全に機能するミニオンサーバーにもなります。この構成のアイデアは、https：//github.com/bketelsen/coreos-kubernetes-digitalocean [CoreOSでのKubernetesのセットアップに関するブライアンケテルソンのガイド]から取得されました。

上記のガイドに従ってクラスターを作成した場合、通信に各サーバーのプライベートIPv4を使用するように、「+ etcd 」と「 fleet +」の両方を設定する必要があります。パブリックIPアドレスは、ローカルマシンからの接続に使用できます。

このガイドでは、この基本的なCoreOSクラスターを使用して、その上に多数のサービスをインストールします。

最初に、コンテナ通信用の個々のサブネットを各マシンに提供するネットワークファブリックレイヤーである「+ flannel +」を設定します。これは、ネットワーク環境に関するKubernetesの仮定に適応するために作成された比較的新しいCoreOSプロジェクトです。

このネットワーク層を展開に使用するようにDockerを構成します。さらに、Kubernetesをセットアップします。これにはいくつかの部分が含まれます。プロキシサービス、APIレイヤー、およびKubeletと呼ばれるノードレベルの「ポッド」管理システムを構成する必要があります。

フランネルネットワークファブリックレイヤーを作成する

最初に行う必要があるのは、 `+ flannel +`サービスを設定することです。これは、クラスター内の各マシンに個別のサブネットを提供するコンポーネントです。 Dockerは、これをデプロイに使用するように構成されます。これは基本的な要件であるため、開始するのに最適な場所です。

この記事の執筆時点では、プロジェクトによって提供される「+ flannel +」のビルド済みバイナリはありません。このため、バイナリをビルドして自分でインストールする必要があります。ビルド時間を節約するために、これを単一のマシンでビルドし、後で実行可能ファイルを他のノードに転送します。

CoreOSの多くの部分と同様に、FlannelはGoプログラミング言語で構築されています。パッケージを構築するために完全なGo環境をセットアップするのではなく、この目的のために事前に構築されたコンテナを使用します。 Googleは、これらのタイプの状況専用のGoコンテナを維持しています。

インストールするすべてのアプリケーションは、 `+ / opt / bin +`ディレクトリに配置されますが、CoreOSでは自動的に作成されません。今すぐディレクトリを作成します。

sudo mkdir -p /opt/bin

これで、Goコンテナを使用してプロジェクトをビルドできます。このDockerコマンドを実行して、Docker Hubからイメージを取得し、コンテナーを実行し、コンテナー内でパッケージをダウンロードしてビルドします。

docker run -i -t google/golang /bin/bash -c "go get github.com/coreos/flannel"

操作が完了すると、コンパイルされたバイナリをコンテナからコピーできます。まず、コンテナIDを知る必要があります。

docker ps -l -q

結果は次のようなIDになります。

このIDを使用して、 `+ / opt / bin `ディレクトリへのコピー操作を指定できます。バイナリはコンテナ内の「 / gopath / bin / flannel 」に配置されています。 ` / opt / bin `ディレクトリは ` core `ユーザーが書き込みできないため、 ` sudo +`を使用する必要があります。

sudo docker cp :/gopath/bin/flannel /opt/bin/

これで、最初のマシンでフランネルを使用できます。少し後、これを他のマシンにコピーします。

Kubernetesバイナリをビルドする

Kubernetesは、非常に多くの異なるアプリケーションとレイヤードテクノロジーで構成されています。現在、プロジェクトには、必要なさまざまなコンポーネントのビルド済みバイナリが含まれていません。代わりに自分で構築します。

サーバーの_one_でのみこのプロセスを完了します。サーバーは本質的に統一されているため、生成するバイナリを転送するだけで、不必要なビルド時間を回避できます。

最初のステップは、GitHubリポジトリからプロジェクトを複製することです。それをホームディレクトリにクローンします：

cd ~
git clone https://github.com/GoogleCloudPlatform/kubernetes.git

次に、リポジトリ内のビルドディレクトリに移動します。ここから、付属のスクリプトを使用してバイナリをビルドできます。

cd kubernetes/build
./release.sh

このプロセスにはかなり時間がかかります。 Dockerコンテナを起動して、必要なバイナリパッケージをビルドします。

ビルドプロセスが完了すると、 `+〜/ kubernetes / _output / dockerized / bin / linux / amd64 +`ディレクトリでバイナリを見つけることができます。

cd ~/kubernetes/_output/dockerized/bin/linux/amd64
ls

e2e          kube-apiserver           kube-proxy      kubecfg  kubelet
integration  kube-controller-manager  kube-scheduler  kubectl  kubernetes

これらを前に作成した `+ / opt / bin +`ディレクトリに転送します：

sudo cp * /opt/bin

最初のマシンには、プロジェクトに必要なすべてのバイナリが含まれています。これで、他のサーバーでこれらのアプリケーションを取得することに集中できます。

実行可能ファイルを他のサーバーに転送する

最初のマシンには、Kubernetesクラスターの起動に必要なすべてのコンポーネントがあります。これが機能する前に、これらを他のマシンにコピーする必要があります。

Kubernetesは統一されたインストールではないため（1つのマスターと複数のミニオンがあります）、各ホストはすべてのバイナリを必要としません。各ミニオンサーバーに必要なのは、スケジューラ、ドッカー、プロキシ、kubelet、およびflannel実行可能ファイルのみです。

ただし、すべての実行可能ファイルを転送すると、今後の柔軟性が高まります。それも簡単です。このガイドのすべてを転送します。

最初のマシンに接続したとき、（エージェントを起動してキーを追加した後） `+ -A +`フラグで接続してSSHエージェント情報を転送する必要があります。これは重要なステップです。以前にこのフラグを渡さなかった場合は、切断して再接続します。

https://www.digitalocean.com/community/tutorials/how-to-connect-to-の* Step 2-Authenticate *セクションから `+ eval `および ` ssh-add `コマンドを実行する必要があります。 your-droplet-with-ssh＃ssh-login-as-root [このチュートリアル]は、 ` -A +`で接続する前に行います。

バイナリを配置したディレクトリに移動することから始めます。

cd /opt/bin

これで、このディレクトリ内のファイルを他のホストにコピーできます。これを行うには、実行可能ファイルをシェルの標準出力に直接tarします。次に、これをSSHコマンドにパイプして、他のホストの1つに接続します。

使用するSSHコマンドは、他のホストに `+ / opt / bin +`ディレクトリを作成し、ディレクトリに変更し、SSHトンネルを介して受信した情報を展開します。コマンド全体は次のようになります。

tar -czf - . | ssh core@ "sudo mkdir -p /opt/bin; cd /opt/bin; sudo tar xzvf -"

これにより、すべての実行可能ファイルが指定したIPアドレスに転送されます。 3番目のホストを使用してコマンドを再度実行します。

tar -czf - . | ssh core@ "sudo mkdir -p /opt/bin; cd /opt/bin; sudo tar xzvf -"

これで、3台のマシンにすべての実行可能ファイルが配置されました。

マスター固有のサービスのセットアップ

次のステップは、 `+ systemd +`ユニットファイルを設定して、新しいアプリケーションを正しく設定および起動することです。まず、マスターサーバーでのみ実行されるアプリケーションを処理します。

これらのファイルを `+ / etc / systemd / system`ディレクトリに配置します。今すぐ移動する：

cd /etc/systemd/system

これで、サービスファイルの作成を開始できます。マスターのみに2つのファイルを作成し、ミニオンにも属する5つのファイルを作成します。これらのファイルはすべて `+ / etc / systemd / system / *。service +`にあります。

マスターファイル：

+ apiserver.service +
+ controller-manager.service +

すべてのサーバーのミニオンファイル：

+ scheduler.service +
+ flannel.service +
+ docker.service +
+ proxy.service +
+ kubelet.service +

APIサーバーユニットファイルを作成する

最初に設定するファイルは、APIサーバーのユニットファイルです。 APIサーバーは、クラスターに関する情報を提供し、情報を変更するポストリクエストを処理し、各サーバーで作業をスケジュールし、共有情報を同期するために使用されます。

簡単にするために、このユニットファイルを「+ apiserver.service +」と呼びます。今すぐそのファイルを作成して開きます。

sudo vim apiserver.service

このファイル内で、サービスに関する基本的なメタデータから始めます。 `+ etcd +`およびDockerサービスが起動して実行されるまで、このユニットが開始されないようにする必要があります。

[Unit]
Description=Kubernetes API Server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

次に、 `+ [Service] +`セクションを完成させます。これは主に、環境を記述するいくつかのパラメーターでAPIサーバーを起動するために使用されます。再起動条件も設定します。

[Unit]
Description=Kubernetes API Server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
ExecStart=/opt/bin/kube-apiserver \
-address=127.0.0.1 \
-port=8080 \
-etcd_servers=http://127.0.0.1:4001 \
-portal_net=10.100.0.0/16 \
-logtostderr=true
ExecStartPost=-/bin/bash -c "until /usr/bin/curl http://127.0.0.1:8080; do echo \"waiting for API server to come online...\"; sleep 3; done"
Restart=on-failure
RestartSec=5

上記のセクションでは、サーバーが実行されるネットワークアドレスとポート、および「+ etcd 」がリッスンしている場所を設定します。 ` portal_net `パラメーターは、 ` flannel +`サービスが使用するネットワーク範囲を提供します。

サービスを開始した後、それがループで稼働していることを確認します。これにより、依存サービスが開始される前に、サービスが実際に接続を受け入れることができます。これがないと、依存サービスでエラーが発生し、手動で再起動する必要があります。

最後に、このユニットをインストールする必要があります。マシンが完全に起動したときにホストにこのサービスを開始するように指示する `+ [Install] +`セクションを使用してこれを実行できます。

[Unit]
Description=Kubernetes API Server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
ExecStart=/opt/bin/kube-apiserver \
-address=127.0.0.1 \
-port=8080 \
-etcd_servers=http://127.0.0.1:4001 \
-portal_net=10.100.0.0/16 \
-logtostderr=true
ExecStartPost=-/bin/bash -c "until /usr/bin/curl http://127.0.0.1:8080; do echo \"waiting for API server to come online...\"; sleep 3; done"
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

終了したら、ファイルを閉じます。

Controller Managerユニットファイルを作成する

Kubernetesが必要とする次の要素は、Controller Managerサーバーです。このコンポーネントは、クラスター単位間でデータ複製を実行するために使用されます。

同じディレクトリで `+ controller-manager.service +`というファイルを開きます：

sudo vim controller-manager.service

再び基本的なメタデータから始めます。これは、最後のファイルと同じ形式に従います。他の依存関係に加えて、このサービスは設定したAPIサーバーユニットの後に起動する必要があります。

[Unit]
Description=Kubernetes Controller Manager
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

このファイルの `+ [Service] +`部分については、実行可能ファイルにいくつかのパラメーターを渡すだけです。主に、アプリケーションをAPIサーバーの場所に向けています。ここでは、各マシンのプライベートIPアドレスをコンマで区切って渡しました。これらの値を変更して、独自の構成をミラーリングします。繰り返しますが、Kubernetesクラスターが正しく機能するために必要であるため、このユニットが障害時に再起動することを確認します。

[Unit]
Description=Kubernetes Controller Manager
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

[Service]
ExecStart=/opt/bin/kube-controller-manager \
-master=http://127.0.0.1:8080 \
-machines=,,
Restart=on-failure
RestartSec=5

また、このユニットが起動時にも起動するように、同じインストール手順を使用します。

[Unit]
Description=Kubernetes Controller Manager
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

[Service]
ExecStart=/opt/bin/kube-controller-manager \
-master=http://127.0.0.1:8080 \
-machines=,,
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

完了したら、ファイルを保存して閉じます。

クラスタサービスのセットアップ

マスター固有のサービスが構成されたので、*すべて*のマシンに存在する必要があるユニットファイルを構成できます。これは、これらのファイルをマスターサーバーとミニオンサーバーの両方に追加し、それに応じて構成する必要があることを意味します。

これらの5つのファイルは、すべてのマシンの `+ / etc / systemd / system / *。service +`に作成する必要があります。

+ scheduler.service +
+ flannel.service +
+ docker.service +
+ proxy.service +
+ kubelet.service +

スケジューラユニットファイルを作成する

次のコンポーネントはスケジューラです。スケジューラーは、どのミニオンでワークロードを実行するかを決定し、これが起こるように通信します。

このユニットのファイルを今すぐ作成して開きます。

sudo vim scheduler.service

このユニットは、最後のユニットとほとんど同じ方法で開始します。同じサービスすべてに依存しています。

[Unit]
Description=Kubernetes Scheduler
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

サービスセクション自体は非常に簡単です。 APIサーバーが配置されているネットワークアドレスとポートで実行可能ファイルをポイントするだけです。繰り返しますが、障害が発生した場合はサービスを再起動します。

インストールセクションは、これまで見てきた他のセクションを反映しています：

[Unit]
Description=Kubernetes Scheduler
After=etcd.service
After=docker.service
After=apiserver.service
Wants=etcd.service
Wants=docker.service
Wants=apiserver.service

[Service]
ExecStart=/opt/bin/kube-scheduler -master=127.0.0.1:8080
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

終了したら、ファイルを保存して閉じます。

フランネルユニットファイルを作成する

立ち上げて実行する必要がある次のコンポーネントは、ネットワークファブリックレイヤーである `+ flannel +`です。これは、各ノードにDockerコンテナ用の独自のサブネットを与えるために使用されます。

繰り返しますが、それぞれのマシンで、 `+ systemd +`設定ディレクトリに移動します：

cd /etc/systemd/system

テキストエディターで `+ flannel +`ユニットファイルを作成して開きます。

sudo vim flannel.service

このファイルの内部では、メタデータ情報から始めます。このサービスはサブネット情報を登録するために「+ etcd 」を必要とするため、「 etcd +」の後にこれを開始する必要があります。

[Unit]
Description=Flannel network fabric for CoreOS
Requires=etcd.service
After=etcd.service

`+ [Service] `セクションでは、最初に ` / etc / environment +`ファイルを取得して、ホストのプライベートIPアドレスにアクセスできるようにします。

次のステップは、サブネット範囲を「+ etcd 」に登録しようとする「 ExecStartPre = 」行を配置することです。成功するまで、etcdに継続的に登録しようとします。このガイドでは、「 10.100.0.0/16+」の範囲を使用します。

次に、環境ファイルから取得したプライベートIPアドレスで「+ flannel +」を開始します。

その後、 `+ flannel `がその情報をファイルに書き込んだかどうかを確認し（Dockerがすぐに読み取れるように）、そうでない場合はスリープします。これにより、Dockerサービスは、ファイルが使用可能になる前にファイルを読み取ろうとしません（これは、最初にオンラインになるサーバーで発生する可能性があります）。通常のパラメーターを使用して再起動を設定し、 ` multi-user.target +`を使用してユニットを再度インストールします。

[Unit]
Description=Flannel network fabric for CoreOS
Requires=etcd.service
After=etcd.service

[Service]
EnvironmentFile=/etc/environment
ExecStartPre=-/bin/bash -c "until /usr/bin/etcdctl set /coreos.com/network/config '{\"Network\": \"10.100.0.0/16\"}'; do echo \"waiting for etcd to become available...\"; sleep 5; done"
ExecStart=/opt/bin/flannel -iface=${COREOS_PRIVATE_IPV4}
ExecStartPost=-/bin/bash -c "until [ -e /run/flannel/subnet.env ]; do echo \"waiting for write.\"; sleep 3; done"
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

完了したら、ファイルを保存して閉じます。他のホストで同じファイルを作成します。

Dockerユニットファイルを作成する

次に作成するファイルは、実際には `+ / opt / bin `ディレクトリ内の実行可能ファイルとは関係ありません。構成したばかりの ` flannel +`ネットワークオーバーレイの知識でサービスが開始されるように、Dockerサービスファイルを作成する必要があります。

テキストエディターで適切なユニットファイルを作成します。

sudo vim docker.service

通常のメタデータから始めます。 `+ flannel +`サービスを設定してオンラインにした後、これを開始する必要があります。

[Unit]
Description=Docker container engine configured to run with flannel
Requires=flannel.service
After=flannel.service

`+ [Service] `セクションでは、作成中の環境変数を保存するために ` flannel +`が使用するファイルを取得する必要があります。これには、現在のホストのサブネット情報が含まれます。

次に、現在の `+ docker0 `ブリッジインターフェイスが実行中の場合はそれを停止し、削除します。これにより、クリーンな状態でDockerを再起動できます。プロセスは、「 flannel 」ネットワーク情報を使用して「 docker0 +」インターフェースを設定します。

他のユニットで使用していたのと同じ再起動と `+ [Install] +`の詳細を使用します。

[Unit]
Description=Docker container engine configured to run with flannel
Requires=flannel.service
After=flannel.service

[Service]
EnvironmentFile=/run/flannel/subnet.env
ExecStartPre=-/usr/bin/ip link set dev docker0 down
ExecStartPre=-/usr/sbin/brctl delbr docker0
ExecStart=/usr/bin/docker -d -s=btrfs -H fd:// --bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU}
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

完了したら、ファイルを保存して閉じます。各ホストでこの同じファイルを作成します。

プロキシユニットファイルを作成する

次に議論する論理ユニットは、各クラスターメンバーが実行するプロキシサーバーです。 Kubernetesプロキシサーバーは、コンテナとの間でトラフィックをルーティングおよび転送するために使用されます。

テキストエディターでプロキシユニットファイルを開きます。

sudo vim proxy.service

メタデータセクションでは、 `+ etcd `とDockerの依存関係を定義する必要があります。 ` [Service] `セクションでは、ローカルの ` etcd +`サーバーのアドレスで実行可能ファイルを起動するだけです。再起動の構成とインストールの詳細は、以前のサービスファイルをミラーリングします。

[Unit]
Description=Kubernetes proxy server
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
ExecStart=/opt/bin/kube-proxy -etcd_servers=http://127.0.0.1:4001 -logtostderr=true
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

完了したらファイルを保存します。各ホストでこの同じファイルを作成します。

Kubeletユニットファイルを作成する

次に、Kubeletユニットファイルを作成します。このコンポーネントは、コンテナの展開を管理するために使用されます。コンテナが存在するはずの状態にあることを確認し、展開の望ましい状態の変化についてシステムを監視します。

テキストエディターでファイルを作成して開きます。

sudo vim kubelet.service

メタデータセクションには、「+ etcd +」とDockerに関する同じ依存情報が含まれます。

[Unit]
Description=Kubernetes Kubelet
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

`+ [Service] `セクションでは、ホストのプライベートIPアドレスにアクセスするために ` / etc / environment`ファイルを再度取得する必要があります。次に、アドレスとポートを設定して、 `+ kubelet `実行可能ファイルを呼び出します。また、ホスト名をオーバーライドして同じプライベートIPアドレスを使用し、サービスがローカルの ` etcd +`インスタンスを指すようにします。使用していたのと同じ再起動とインストールの詳細を提供します。

[Unit]
Description=Kubernetes Kubelet
After=etcd.service
After=docker.service
Wants=etcd.service
Wants=docker.service

[Service]
EnvironmentFile=/etc/environment
ExecStart=/opt/bin/kubelet \
-address=${COREOS_PRIVATE_IPV4} \
-port=10250 \
-hostname_override=${COREOS_PRIVATE_IPV4} \
-etcd_servers=http://127.0.0.1:4001 \
-logtostderr=true
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

完了したら、ファイルを保存して閉じます。

サービスを有効にする

すべてのサービスファイルが開始されたので、これらのユニットを有効にできます。これにより、各ユニットの `+ [Install] +`セクションの情報が処理されます。

私たちのユニットはマルチユーザーターゲットに必要とされているため、システムがサーバーをマルチユーザーモードにしようとすると、すべてのサービスが自動的に開始されます。

これを実現するには、 `+ / etc / systemd / system`ディレクトリに移動します：

cd /etc/systemd/system

ここから、すべてのスクリプトを有効にできます。

sudo systemctl enable *

これにより、ユニットファイルへのシンボリックリンクを持つ `+ multi-user.target.wants `ディレクトリが作成されます。このディレクトリは、ブートプロセスの最後に向かって「 systemd +」によって処理されます。

各サーバーでこの手順を繰り返します。

サービスが有効になったので、サーバーを順番に再起動できます。

マスターサーバーから開始しますが、任意の順序で実行できます。これらのサービスを開始するためにリブートする必要はありませんが、そうすることで、ユニットファイルがシームレスな依存関係チェーンを許可する方法で書き込まれていることが保証されます。

sudo reboot

マスターがオンラインに戻ったら、ミニオンサーバーを再起動できます。

sudo reboot

すべてのサーバーがオンラインになったら、サービスが正しく開始されたことを確認します。これを確認するには、次のように入力します。

systemctl status

または、次のように入力してジャーナルにアクセスできます。

journalctl -b -u

サービスが正常に稼働していることを示す兆候を探してください。問題がある場合、特定のサービスの再起動が役立つ場合があります。

sudo systemctl restart

終了したら、マスターサーバーからマシンを表示できるようになります。マスターサーバーにログインした後、次のように入力して、すべてのサーバーが利用可能であることを確認します。

kubecfg list minions

Minion identifier
----------

今後のガイドでは、Kubernetesを使用してCoreOSクラスター上のサービスをスケジュールおよび制御する方法について説明します。

結論

これで、CoreOSクラスター全体でKubernetesをセットアップする必要があります。これにより、論理グループでサービスを操作するための優れた管理およびスケジューリングインターフェイスが提供されます。

おそらく、上記の手順が非常に手動のプロセスにつながることに気づいたでしょう。これの大部分は、マシン上にバイナリを構築したためです。プライベートネットワーク内でアクセス可能なWebサーバーでバイナリをホストする場合、バイナリをプルダウンし、特別なcloud-configファイルを作成して自動的に構成できます。

Cloud-configファイルは十分な柔軟性を備えているため、ほとんどのユニットファイルを変更せずに挿入でき（ただし、各ノードのIPにアクセスする必要がある `+ apiserver.service +`ファイルを除く）、CoreOSとして起動できます。ノードが起動します。これはこのガイドの範囲外ですが、プロセスを自動化するという点で次の良いステップです。

TOC