CoreOSクラスター上にKubernetesをインストールして構成する方法
ステータス:期限切れ
この記事は最新ではありません。 この記事の更新を書くことに興味がある場合は、DigitalOceanが技術チュートリアルを公開したいのをご覧ください。
理由: 2016年12月22日、CoreOSはフリートを維持しなくなったことを発表しました。 CoreOSは、すべてのクラスタリングのニーズにKubernetesを使用することをお勧めします。
代わりに参照してください:フリートなしでCoreOSでKubernetesを使用するガイダンスについては、CoreOSドキュメントのKubernetesを参照してください。
序章
Kubernetesは、クラスター化された環境全体でDockerコンテナー内に構築されたアプリケーションを管理するために設計されたシステムです。 デプロイとスケーリングを含む、コンテナ化されたアプリケーションのライフサイクル全体を処理します。
このガイドでは、CoreOSクラスターでKubernetesを使い始める方法を示します。 このシステムにより、Kubernetesが「ポッド」と呼ぶものを使用して、関連するサービスをグループ化して1つのホストに1つのユニットとしてデプロイできるようになります。 また、ヘルスチェック機能、高可用性、およびリソースの効率的な使用も提供します。
このチュートリアルは、Kubernetesv0.7.0でテストされました。 このソフトウェアは頻繁に変更されることに注意してください。 バージョンを確認するには、インストールしたら、次のコマンドを実行します。
kubecfg -version
前提条件と目標
以前のCoreOSガイドで使用したものと同じ基本的なCoreOSクラスターから始めます。 この3つのメンバーのクラスターを稼働させるには、CoreOSクラスタリングガイドに従ってください。
これにより、構成する3つのサーバーが提供されます。 各ノードは基本的にCoreOSレベルで交換可能ですが、Kubernetes内では、より特殊な役割を割り当てる必要があります。 マスターとして機能するノードが1つ必要です。これにより、APIサーバーやコントローラーマネージャーなどのいくつかの追加サービスが実行されます。
このガイドでは、次の詳細を使用します。
ホスト名 | パブリックIPv4 | プライベートIPv4 | 役割 |
---|---|---|---|
coreos-1 | 192.168.2.1 | 10.120.0.1 | マスター |
coreos-2 | 192.168.2.2 | 10.120.0.2 | ミニオン1 |
coreos-3 | 192.168.2.3 | 10.120.0.3 | Minion2 |
以下の構成では、マスターは、作業を完了することができる完全に機能するミニオンサーバーでもあります。 この構成のアイデアは、CoreOSでのKubernetesのセットアップに関するBrianKetelsonのガイドから引用したものです。
上記のガイドに従ってクラスターを作成した場合は、etcd
とfleet
の両方を、各サーバーのプライベートIPv4を通信に使用するように構成する必要があります。 パブリックIPアドレスは、ローカルマシンからの接続に使用できます。
このガイドでは、この基本的なCoreOSクラスターを取り上げ、その上にいくつかのサービスをインストールします。
まず、flannel
を構成します。これは、コンテナー通信用の個別のサブネットを各マシンに提供するネットワークファブリックレイヤーです。 これは、ネットワーキング環境に関するKubernetesの仮定に適応するために大部分が作成された、比較的新しいCoreOSプロジェクトです。
デプロイにこのネットワーク層を使用するようにDockerを構成します。 これに加えて、Kubernetesをセットアップします。 これにはいくつかの要素が含まれます。 プロキシサービス、APIレイヤー、およびKubeletと呼ばれるノードレベルの「ポッド」管理システムを構成する必要があります。
フランネルネットワークファブリックレイヤーを作成する
最初に行う必要があるのは、flannel
サービスを構成することです。 これは、クラスター内の各マシンに個別のサブネットを提供するコンポーネントです。 Dockerは、デプロイメントにこれを使用するように構成されます。 これは基本的な要件であるため、開始するのに最適な場所です。
この記事の執筆時点では、プロジェクトによって提供されるflannel
のビルド済みバイナリはありません。 このため、バイナリをビルドして自分でインストールする必要があります。 ビルド時間を節約するために、これを1台のマシンでビルドし、後で実行可能ファイルを他のノードに転送します。
CoreOSの多くの部分と同様に、FlannelはGoプログラミング言語で構築されています。 パッケージをビルドするために完全なGo環境をセットアップするのではなく、この目的のために事前にビルドされたコンテナーを使用します。 Googleは、これらのタイプの状況に特化したGoコンテナを維持しています。
インストールするすべてのアプリケーションは、CoreOSで自動的に作成されない/opt/bin
ディレクトリに配置されます。 今すぐディレクトリを作成します。
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になります。
004e7a7e4b70
このIDを使用して、/opt/bin
ディレクトリへのコピー操作を指定できます。 バイナリはコンテナ内の/gopath/bin/flannel
に配置されています。 /opt/bin
ディレクトリはcore
ユーザーが書き込むことができないため、sudo
を使用する必要があります。
sudo docker cp 004e7a7e4b70:/gopath/bin/flannel /opt/bin/
これで、最初のマシンでフランネルを使用できるようになりました。 少し後で、これを他のマシンにコピーします。
KubernetesBinariesを構築する
Kubernetesは、かなりの数の異なるアプリケーションと階層化されたテクノロジーで構成されています。 現在、プロジェクトには、必要なさまざまなコンポーネント用のビルド済みのバイナリは含まれていません。 代わりに、自分で作成します。
このプロセスは、サーバーの1つでのみ完了します。 サーバーは本質的に均一であるため、作成するバイナリを転送するだけで、不要なビルド時間を回避できます。
最初のステップは、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つのマスターと複数のミニオンがあります)、各ホストにすべてのバイナリが必要なわけではありません。 各ミニオンサーバーには、スケジューラ、Docker、プロキシ、kubelet、およびフランネルの実行可能ファイルのみが必要です。
ただし、すべての実行可能ファイルを転送すると、将来的に柔軟性が高まります。 それも簡単です。 このガイドのすべてを転送します。
最初のマシンに接続するときは、-A
フラグを使用して接続することにより、SSHエージェント情報を転送する必要があります(エージェントを起動してキーを追加した後)。 これは重要なステップです。 以前にこのフラグを渡さなかった場合は、切断して再接続します。
-A
に接続する前に、ステップ2 —このチュートリアルの[Authenticate]セクションからeval
およびssh-add
コマンドを実行する必要があります。 ]。
バイナリを配置したディレクトリに移動することから始めます。
cd /opt/bin
これで、このディレクトリ内のファイルを他のホストにコピーできます。 これを行うには、実行可能ファイルをシェルの標準に直接タールします。 次に、これをSSHコマンドにパイプして、他のホストの1つに接続します。
使用するSSHコマンドは、他のホストに/opt/bin
ディレクトリを作成し、そのディレクトリに移動して、SSHトンネルを介して受信した情報を解凍します。 コマンド全体は次のようになります。
tar -czf - . | ssh [email protected] "sudo mkdir -p /opt/bin; cd /opt/bin; sudo tar xzvf -"
これにより、すべての実行可能ファイルが指定したIPアドレスに転送されます。 3番目のホストを使用してコマンドを再実行します。
tar -czf - . | ssh [email protected] "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
終了したら、ファイルを閉じます。
ControllerManagerユニットファイルを作成する
Kubernetesに必要な次のピースは、ControllerManagerサーバーです。 このコンポーネントは、クラスターユニット間でデータレプリケーションを実行するために使用されます。
同じディレクトリにある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=10.120.0.1,10.120.0.2,10.120.0.3 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=10.120.0.1,10.120.0.2,10.120.0.3 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 service_name
または、次のように入力してジャーナルにアクセスできます。
journalctl -b -u service_name
サービスが正しく稼働していることを示す兆候を探します。 問題がある場合は、特定のサービスを再起動すると役立つ場合があります。
sudo systemctl restart service_name
終了すると、マスターサーバーからマシンを表示できるようになります。 マスターサーバーにログインした後、次のように入力して、すべてのサーバーが使用可能であることを確認します。
kubecfg list minions
Minion identifier ---------- 10.200.0.1 10.200.0.2 10.200.0.3
今後のガイドでは、Kubernetesを使用してCoreOSクラスター上のサービスをスケジュールおよび制御する方法について説明します。
結論
これで、CoreOSクラスター全体にKubernetesがセットアップされているはずです。 これにより、論理グループでサービスを操作するための優れた管理およびスケジューリングインターフェイスが提供されます。
上記の手順が非常に手動のプロセスにつながることにおそらくお気づきでしょう。 これの大部分は、マシン上にバイナリを構築したためです。 プライベートネットワーク内でアクセス可能なWebサーバーでバイナリをホストする場合は、バイナリをプルダウンして、特別なcloud-configファイルを作成することで自動的に構成できます。
Cloud-configファイルは十分な柔軟性があるため、ほとんどのユニットファイルを変更せずに挿入でき(各ノードのIPにアクセスする必要があるapiserver.service
ファイルを除く)、CoreOSとして起動できます。ノードが起動します。 これはこのガイドの範囲外ですが、プロセスの自動化という点では次のステップとして適しています。