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

投稿日: 2019-11-08 2022-10-22
タグ: Clustering, CoreOS, Docker, Kubernetes, Networking, Scaling

ステータス：期限切れ

この記事は最新ではありません。この記事の更新を書くことに興味がある場合は、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コンテナを維持しています。

インストールするすべてのアプリケーションは、 /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になります。

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、およびフランネルの実行可能ファイルのみが必要です。

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

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

を実行する必要があります eval と ssh-add ステップ2—このチュートリアルのセクションを認証してから接続する前のコマンド -A.

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

cd /opt/bin

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

使用するSSHコマンドは、 /opt/bin 他のホストのディレクトリに移動し、ディレクトリに移動して、SSHトンネルを介して受信した情報を解凍します。コマンド全体は次のようになります。

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

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

tar -czf - . | ssh core@192.168.2.3 "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 聞いています。 The 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アドレスにアクセスできるようにファイルします。

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

次に、開始します flannel 環境ファイルから取得するプライベートIPアドレスを使用します。

その後、確認したいのですが 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 ディレクトリ。 Dockerサービスファイルを作成して、サービスが flannel 構成したネットワークオーバーレイ。

テキストエディタで適切な単位ファイルを作成します。

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をクリーンな状態で再起動できます。プロセスは、 docker0 を使用したインターフェース flannel ネットワーク情報。

同じ再起動を使用し、 [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] セクションでは、再び調達する必要があります /etc/environment ホストのプライベートIPアドレスにアクセスするためのファイル。その後、 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ファイルは十分な柔軟性があるため、ほとんどのユニットファイルを変更せずに挿入できます（ただし、 apiserver.service ファイル。各ノードのIPにアクセスする必要があります）、CoreOSノードの起動時にそれらを起動します。これはこのガイドの範囲外ですが、プロセスの自動化という点では次のステップとして適しています。

getdocs

13036