著者はhttps://www.brightfunds.org/funds/foss-nonprofits [無料およびオープンソース基金]を選択して、https：//do.co/w4do-cta [Donationsのために書く]の一部として寄付を受け取りましたプログラム。
前書き
https://kubernetes.io [Kubernetes]は、大規模にコンテナを管理するコンテナオーケストレーションシステムです。 Kubernetesは、運用環境でコンテナを実行した経験に基づいてGoogleが最初に開発したオープンソースであり、世界中のコミュニティによって積極的に開発されています。
Kubeadmは、APIサーバー、コントローラーマネージャー、Kube DNSなどのKubernetesコンポーネントのインストールと構成を自動化します。 ただし、ユーザーの作成や、オペレーティングシステムレベルの依存関係とその構成のインストールは処理しません。 これらの予備タスクでは、https：//www.ansible.com/ [Ansible]やhttps://saltstack.com/[SaltStack]などの構成管理ツールを使用できます。 これらのツールを使用すると、追加のクラスターを作成したり、既存のクラスターを再作成したりするのがはるかに簡単になり、エラーが発生しにくくなります。
このガイドでは、AnsibleとKubeadmを使用してゼロからKubernetesクラスターをセットアップし、コンテナー化されたNginxアプリケーションをデプロイします。
目標
クラスターには、次の物理リソースが含まれます。
-
* 1つのマスターノード*
マスターノード（Kubernetesの_node_はサーバーを指します）は、クラスターの状態を管理します。 Etcdを実行し、ワークロードをワーカーノードにスケジュールするコンポーネント間でクラスターデータを保存します。
-
* 2つのワーカーノード*
ワーカーノードは、workloads（つまり、 コンテナ化されたアプリケーションとサービス）が実行されます。 ワーカーは、スケジューリングが完了するとマスターがダウンしても、割り当てられたワークロードを実行し続けます。 ワーカーを追加すると、クラスターの容量を増やすことができます。
このガイドを完了すると、クラスター内のサーバーにアプリケーションが消費するのに十分なCPUリソースとRAMリソースがあれば、コンテナー化されたアプリケーションを実行する準備が整います。 Webアプリケーション、データベース、デーモン、およびコマンドラインツールを含む、ほぼすべての従来のUnixアプリケーションをコンテナ化して、クラスター上で実行することができます。 クラスター自体は、各ノードで約300〜500MBのメモリと10％のCPUを消費します。
クラスターを設定したら、Webサーバーhttps://nginx.org/en/[Nginx]をデプロイして、ワークロードが正しく実行されていることを確認します。
前提条件
-
ローカルLinux / macOS / BSDマシン上のSSHキーペア。 SSHキーを使用したことがない場合は、https：//www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-に従って設定する方法を学習できます。 keys＃generated-and-working-with-ssh-keys [ローカルマシンでSSHキーをセットアップする方法のこの説明]。
-
2 GB以上のRAMとそれぞれ2つのvCPUを備えたDebian 9を実行する3つのサーバー。 SSHキーペアを使用して、rootユーザーとして各サーバーにSSH接続できるはずです。
-
ローカルマシンにインストールされたAnsible。 インストール手順については、http：//docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#installing-the-control-machine [公式のAnsibleインストールドキュメント]に従ってください。
-
Ansibleプレイブックに精通している。 確認するには、https：//www.digitalocean.com/community/tutorials/configuration-management-101-writing-ansible-playbooks [Configuration Management 101：Ansible Playbookの作成]をご覧ください。
-
Dockerイメージからコンテナーを起動する方法に関する知識。 Dockerのインストールと使用方法の「ステップ5-Dockerコンテナの実行」をご覧ください。 Debian 9]では、復習が必要な場合。
手順1-ワークスペースディレクトリとAnsible Inventoryファイルのセットアップ
このセクションでは、ローカルマシン上にワークスペースとして機能するディレクトリを作成します。 Ansibleをローカルで設定して、リモートサーバーと通信し、コマンドを実行できるようにします。 それが完了したら、サーバーのIPアドレスや各サーバーが属するグループなどのインベントリ情報を含む「+ hosts +」ファイルを作成します。
3つのサーバーのうち、1つが「」として表示されるIPを持つマスターになります。 他の2つのサーバーはワーカーであり、IPが「」と「++」になります。
ローカルマシンのホームディレクトリに「〜/ kube-cluster +」という名前のディレクトリを作成し、そこに「 cd +」を追加します。
mkdir ~/kube-cluster
cd ~/kube-clusterこのディレクトリは、残りのチュートリアルのワークスペースであり、すべてのAnsibleプレイブックが含まれます。 また、内部ですべてのローカルコマンドを実行するディレクトリにもなります。
`+ nano `またはお好みのテキストエディターを使用して、 `〜/ kube-cluster / hosts +`という名前のファイルを作成します。
nano ~/kube-cluster/hosts次のテキストをファイルに追加します。これにより、クラスターの論理構造に関する情報が指定されます。
〜/ kube-cluster / hosts
[masters]
master ansible_host= ansible_user=root
[workers]
worker1 ansible_host= ansible_user=root
worker2 ansible_host= ansible_user=root
[all:vars]
ansible_python_interpreter=/usr/bin/python3Ansibleのhttp://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html[inventory files]は、IPアドレス、リモートユーザー、サーバーのグループ化などのサーバー情報を指定するために使用されることを思い出してください。コマンドを実行するための単一ユニット。 `+〜/ kube-cluster / hosts +`がインベントリファイルになり、クラスターの論理構造を指定する2つのAnsibleグループ（* masters および workers *）を追加しました。
-
masters *グループには、マスターノードのIP（
++）をリストし、Ansibleがルートユーザーとしてリモートコマンドを実行することを指定する「master」という名前のサーバーエントリがあります。
同様に、* workers *グループには、ワーカーサーバー用の2つのエントリ（ `と `）があり、それらはルートとして `+ ansible_user +`も指定します。
ファイルの最後の行は、管理操作にリモートサーバーのPython 3インタープリターを使用するようAnsibleに指示しています。
テキストを追加したら、ファイルを保存して閉じます。
グループでサーバーインベントリを設定したら、オペレーティングシステムレベルの依存関係のインストールと構成設定の作成に移りましょう。
手順2-すべてのリモートサーバーでの非ルートユーザーの作成
このセクションでは、すべてのサーバーでsudo特権を持つ非rootユーザーを作成して、非特権ユーザーとして手動でSSHでログインできるようにします。 これは、たとえば、 `+ top / htop +`などのコマンドを使用してシステム情報を表示したり、実行中のコンテナーのリストを表示したり、rootが所有する構成ファイルを変更したりする場合に役立ちます。 これらの操作はクラスターのメンテナンス中に定期的に実行され、そのようなタスクに非rootユーザーを使用すると、重要なファイルを変更または削除したり、他の危険な操作を誤って実行したりするリスクが最小限に抑えられます。
ワークスペースに `+〜/ kube-cluster / initial.yml +`という名前のファイルを作成します：
nano ~/kube-cluster/initial.yml次に、次の_play_をファイルに追加して、すべてのサーバーでsudo特権を持つ非rootユーザーを作成します。 Ansibleでのプレイとは、特定のサーバーとグループを対象とする実行されるステップの集まりです。 次のプレイは、非ルートsudoユーザーを作成します。
〜/ kube-cluster / initial.yml
- hosts: all
become: yes
tasks:
- name: create the 'sammy' user
user: name=sammy append=yes state=present createhome=yes shell=/bin/bash
- name: allow 'sammy' to have passwordless sudo
lineinfile:
dest: /etc/sudoers
line: 'sammy ALL=(ALL) NOPASSWD: ALL'
validate: 'visudo -cf %s'
- name: set up authorized keys for the sammy user
authorized_key: user=sammy key="{{item}}"
with_file:
- ~/.ssh/id_rsa.pubこのプレイブックの機能の内訳は次のとおりです。
-
非rootユーザー `+ sammy +`を作成します。
-
`+ sammy `ユーザーがパスワードプロンプトなしで ` sudo `コマンドを実行できるように、 ` sudoers +`ファイルを設定します。
-
ローカルマシンの公開キー（通常は
+〜/ .ssh / id_rsa.pub +）をリモートの `+ sammy `ユーザーの承認済みキーリストに追加します。 これにより、 ` sammy +`ユーザーとして各サーバーにSSH接続できます。
テキストを追加したら、ファイルを保存して閉じます。
次に、ローカルで実行してプレイブックを実行します：
ansible-playbook -i hosts ~/kube-cluster/initial.ymlコマンドは2〜5分以内に完了します。 完了すると、次のような出力が表示されます。
OutputPLAY [all] ****
TASK [Gathering Facts] ****
ok: [master]
ok: [worker1]
ok: [worker2]
TASK [create the 'sammy' user] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [allow 'sammy' user to have passwordless sudo] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [set up authorized keys for the sammy user] ****
changed: [worker1] => (item=ssh-rsa AAAAB3...)
changed: [worker2] => (item=ssh-rsa AAAAB3...)
changed: [master] => (item=ssh-rsa AAAAB3...)
PLAY RECAP ****
master : ok=5 changed=4 unreachable=0 failed=0
worker1 : ok=5 changed=4 unreachable=0 failed=0
worker2 : ok=5 changed=4 unreachable=0 failed=0準備が完了したら、Kubernetes固有の依存関係のインストールに進むことができます。
ステップ3-Kubernetes依存関係のインストール
このセクションでは、Debianのパッケージマネージャーを使用してKubernetesに必要なオペレーティングシステムレベルのパッケージをインストールします。 これらのパッケージは次のとおりです。
-
Docker-コンテナーランタイム。 コンテナを実行するコンポーネントです。 rktなどの他のランタイムのサポートは、Kubernetesで活発に開発されています。
-
+ kubeadm +-標準的な方法でクラスターのさまざまなコンポーネントをインストールおよび構成するCLIツール。 -
+ kubelet +-すべてのノードで実行され、ノードレベルの操作を処理するシステムサービス/プログラム。 -
+ kubectl +-APIサーバーを介してクラスターにコマンドを発行するために使用されるCLIツール。
ワークスペースに `+〜/ kube-cluster / kube-dependencies.yml +`という名前のファイルを作成します：
nano ~/kube-cluster/kube-dependencies.yml次の再生をファイルに追加して、これらのパッケージをサーバーにインストールします。
〜/ kube-cluster / kube-dependencies.yml
- hosts: all
become: yes
tasks:
- name: install remote apt deps
apt:
name: "{{ item }}"
state: present
with_items:
- apt-transport-https
- ca-certificates
- gnupg2
- software-properties-common
- name: add Docker apt-key
apt_key:
url: https://download.docker.com/linux/debian/gpg
state: present
- name: add Docker's APT repository
apt_repository:
repo: deb https://download.docker.com/linux/debian stretch stable
state: present
filename: 'docker'
- name: install Docker
apt:
name: docker-ce
state: present
update_cache: true
- name: add Kubernetes apt-key
apt_key:
url: https://packages.cloud.google.com/apt/doc/apt-key.gpg
state: present
- name: add Kubernetes' APT repository
apt_repository:
repo: deb http://apt.kubernetes.io/ kubernetes-xenial main
state: present
filename: 'kubernetes'
- name: install kubelet
apt:
name: kubelet=1.14.0-00
state: present
update_cache: true
- name: install kubeadm
apt:
name: kubeadm=1.14.0-00
state: present
- hosts: master
become: yes
tasks:
- name: install kubectl
apt:
name: kubectl=1.14.0-00
state: present
force: yesプレイブックの最初のプレイは次のことを行います。
-
リモートリポジトリからパッケージを追加、検証、インストールするための依存関係を追加します。
-
キー検証のためにDocker APTリポジトリのapt-keyを追加します。
-
コンテナランタイムであるDockerをインストールします。
-
キー検証用にKubernetes APTリポジトリのapt-keyを追加します。
-
Kubernetes APTリポジトリをリモートサーバーのAPTソースリストに追加します。
-
+ kubelet`と+ kubeadm`をインストールします。
2番目のプレイは、マスターノードに `+ kubectl`をインストールする単一のタスクで構成されます。
完了したら、ファイルを保存して閉じます。
次に、ローカルで実行してプレイブックを実行します：
ansible-playbook -i hosts ~/kube-cluster/kube-dependencies.yml完了すると、次のような出力が表示されます。
OutputPLAY [all] ****
TASK [Gathering Facts] ****
ok: [worker1]
ok: [worker2]
ok: [master]
TASK [install Docker] ****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [install APT Transport HTTPS] *****
ok: [master]
ok: [worker1]
changed: [worker2]
TASK [add Kubernetes apt-key] *****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [add Kubernetes' APT repository] *****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [install kubelet] *****
changed: [master]
changed: [worker1]
changed: [worker2]
TASK [install kubeadm] *****
changed: [master]
changed: [worker1]
changed: [worker2]
PLAY [master] *****
TASK [Gathering Facts] *****
ok: [master]
TASK [install kubectl] ******
ok: [master]
PLAY RECAP ****
master : ok=9 changed=5 unreachable=0 failed=0
worker1 : ok=7 changed=5 unreachable=0 failed=0
worker2 : ok=7 changed=5 unreachable=0 failed=0実行後、Docker、 + kubeadm +、および `+ kubelet `がすべてのリモートサーバーにインストールされます。 ` kubectl `は必須コンポーネントではなく、クラスターコマンドの実行にのみ必要です。 マスターからのみ ` kubectl `コマンドを実行するため、このコンテキストではマスターノードのみにインストールするのが理にかなっています。 ただし、 ` kubectl +`コマンドは、任意のワーカーノードから、またはクラスターを指すようにインストールおよび構成できる任意のマシンから実行できることに注意してください。
これで、すべてのシステム依存関係がインストールされました。 マスターノードをセットアップして、クラスターを初期化しましょう。
手順4-マスターノードのセットアップ
このセクションでは、マスターノードを設定します。 ただし、プレイブックを作成する前に、クラスターに両方が含まれるため、_Pods_や_Pod Network Plugins_などのいくつかの概念を説明する価値があります。
ポッドは、1つ以上のコンテナーを実行するアトミックユニットです。 これらのコンテナは、ファイルボリュームやネットワークインターフェイスなどのリソースを共有します。 ポッドはKubernetesのスケジューリングの基本単位です。ポッド内のすべてのコンテナーは、ポッドがスケジュールされている同じノードで実行されることが保証されています。
各ポッドには独自のIPアドレスがあり、1つのノード上のポッドはポッドのIPを使用して別のノード上のポッドにアクセスできる必要があります。 単一ノード上のコンテナは、ローカルインターフェイスを介して簡単に通信できます。 ただし、ポッド間の通信はより複雑であり、1つのノードのポッドから別のノードのポッドにトラフィックを透過的にルーティングできる個別のネットワークコンポーネントが必要です。
この機能は、ポッドネットワークプラグインによって提供されます。 このクラスターでは、https：//github.com/coreos/flannel [Flannel]の安定したパフォーマンスオプションを使用します。
ローカルマシンで `+ master.yml +`という名前のAnsibleプレイブックを作成します。
nano ~/kube-cluster/master.yml次の再生をファイルに追加して、クラスターを初期化し、Flannelをインストールします。
〜/ kube-cluster / master.yml
- hosts: master
become: yes
tasks:
- name: initialize the cluster
shell: kubeadm init --pod-network-cidr=10.244.0.0/16 >> cluster_initialized.txt
args:
chdir: $HOME
creates: cluster_initialized.txt
- name: create .kube directory
become: yes
become_user: sammy
file:
path: $HOME/.kube
state: directory
mode: 0755
- name: copy admin.conf to user's kube config
copy:
src: /etc/kubernetes/admin.conf
dest: /home/sammy/.kube/config
remote_src: yes
owner: sammy
- name: install Pod network
become: yes
become_user: sammy
shell: kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml >> pod_network_setup.txt
args:
chdir: $HOME
creates: pod_network_setup.txtこのプレイの内訳は次のとおりです。
-
最初のタスクは、 `+ kubeadm init `を実行してクラスターを初期化します。 引数 `-pod-network-cidr = 10.244.0.0 / 16 `を渡すと、ポッドIPが割り当てられるプライベートサブネットが指定されます。 フランネルはデフォルトで上記のサブネットを使用します。同じサブネットを使用するように「 kubeadm +」に指示しています。
-
2番目のタスクは、 `+ / home / sammy `に ` .kube +`ディレクトリを作成します。 このディレクトリには、クラスターへの接続に必要な管理キーファイルやクラスターのAPIアドレスなどの構成情報が保持されます。
-
3番目のタスクは、 `+ kubeadm init `から生成された ` / etc / kubernetes / admin.conf `ファイルを非ルートユーザーのホームディレクトリにコピーします。 これにより、 ` kubectl +`を使用して新しく作成されたクラスターにアクセスできます。
-
最後のタスクは、「+ kubectl apply 」を実行して「 Flannel 」をインストールします。 ` kubectl apply -f descriptor。[yml | json] `は、 ` kubectl `に ` descriptor。[yml | json] `ファイルに記述されているオブジェクトを作成するよう指示するための構文です。 ` kube-flannel.yml `ファイルには、クラスターで ` Flannel +`を設定するために必要なオブジェクトの説明が含まれています。
完了したら、ファイルを保存して閉じます。
次を実行して、プレイブックをローカルで実行します。
ansible-playbook -i hosts ~/kube-cluster/master.yml完了すると、次のような出力が表示されます。
Output
PLAY [master] ****
TASK [Gathering Facts] ****
ok: [master]
TASK [initialize the cluster] ****
changed: [master]
TASK [create .kube directory] ****
changed: [master]
TASK [copy admin.conf to user's kube config] *****
changed: [master]
TASK [install Pod network] *****
changed: [master]
PLAY RECAP ****
master : ok=5 changed=4 unreachable=0 failed=0マスターノードのステータスを確認するには、次のコマンドを使用してSSHでマスターノードに接続します。
ssh sammy@マスターノード内で、次を実行します。
kubectl get nodes次の出力が表示されます。
OutputNAME STATUS ROLES AGE VERSION
master Ready master 1d v1.14.0出力には、「+ master 」ノードがすべての初期化タスクを完了し、ワーカーノードの受け入れとAPIサーバーに送信されたタスクの実行を開始できる「 Ready +」状態にあることが示されています。 これで、ローカルマシンからワーカーを追加できます。
ステップ5-ワーカーノードのセットアップ
クラスターにワーカーを追加するには、それぞれに対して単一のコマンドを実行する必要があります。 このコマンドには、マスターのAPIサーバーのIPアドレスとポート、セキュアトークンなどの必要なクラスター情報が含まれます。 セキュアトークンを渡すノードのみがクラスターに参加できます。
ワークスペースに戻って、 `+ workers.yml +`という名前のプレイブックを作成します。
nano ~/kube-cluster/workers.yml次のテキストをファイルに追加して、ワーカーをクラスターに追加します。
〜/ kube-cluster / workers.yml
- hosts: master
become: yes
gather_facts: false
tasks:
- name: get join command
shell: kubeadm token create --print-join-command
register: join_command_raw
- name: set join command
set_fact:
join_command: "{{ join_command_raw.stdout_lines[0] }}"
- hosts: workers
become: yes
tasks:
- name: join cluster
shell: "{{ hostvars['master'].join_command }} >> node_joined.txt"
args:
chdir: $HOME
creates: node_joined.txtプレイブックの機能は次のとおりです。
-
最初のプレイでは、ワーカーノードで実行する必要があるjoinコマンドを取得します。 このコマンドの形式は次のとおりです。`+ kubeadm join --token <token> <master-ip>：<master-port> --discovery-token-ca-cert-hash sha256：<hash> + `。 適切な* token および hash *値を持つ実際のコマンドを取得すると、タスクはそれをファクトとして設定し、次のプレイがその情報にアクセスできるようにします。
-
2番目のプレイには、すべてのワーカーノードでjoinコマンドを実行する単一のタスクがあります。 このタスクが完了すると、2つのワーカーノードがクラスターの一部になります。
完了したら、ファイルを保存して閉じます。
ローカルで実行してプレイブックを実行します：
ansible-playbook -i hosts ~/kube-cluster/workers.yml完了すると、次のような出力が表示されます。
OutputPLAY [master] ****
TASK [get join command] ****
changed: [master]
TASK [set join command] *****
ok: [master]
PLAY [workers] *****
TASK [Gathering Facts] *****
ok: [worker1]
ok: [worker2]
TASK [join cluster] *****
changed: [worker1]
changed: [worker2]
PLAY RECAP *****
master : ok=2 changed=1 unreachable=0 failed=0
worker1 : ok=2 changed=1 unreachable=0 failed=0
worker2 : ok=2 changed=1 unreachable=0 failed=0ワーカーノードを追加すると、クラスターが完全にセットアップされて機能するようになり、ワーカーはワークロードを実行する準備が整います。 アプリケーションをスケジュールする前に、クラスターが意図したとおりに機能していることを確認しましょう。
ステップ6-クラスターの検証
ノードがダウンしているか、マスターとワーカー間のネットワーク接続が正しく機能していないため、セットアップ中にクラスターが失敗することがあります。 クラスターを検証し、ノードが正しく動作していることを確認しましょう。
マスターノードからクラスターの現在の状態をチェックして、ノードの準備ができていることを確認する必要があります。 マスターノードから切断した場合、次のコマンドを使用してSSHでマスターノードに戻すことができます。
ssh sammy@次に、次のコマンドを実行して、クラスターのステータスを取得します。
kubectl get nodes次のような出力が表示されます。
OutputNAME STATUS ROLES AGE VERSION
master Ready master 1d v1.14.0
worker1 Ready <none> 1d v1.14.0
worker2 Ready <none> 1d v1.14.0すべてのノードの値が「+ STATUS 」に対して「 Ready +」の場合、それらはクラスターの一部であり、ワークロードを実行する準備ができていることを意味します。
ただし、いくつかのノードの `+ STATUS `が ` NotReady `である場合、ワーカーノードがまだセットアップを完了していない可能性があります。 5分から10分ほど待ってから、 ` kubectl get nodes `を再実行し、新しい出力を調べます。 いくつかのノードのステータスがまだ「 NotReady +」である場合、前の手順でコマンドを確認して再実行する必要があります。
クラスターが正常に検証されたので、クラスターでサンプルのNginxアプリケーションをスケジュールしましょう。
手順7-クラスターでのアプリケーションの実行
これで、コンテナ化されたアプリケーションをクラスターにデプロイできます。 わかりやすくするために、_Deployments_および_Services_を使用してNginxをデプロイし、このアプリケーションをクラスターにデプロイする方法を見てみましょう。 Dockerイメージ名と関連するフラグ（「+ ports 」や「 volumes +」など）を変更する場合、他のコンテナー化されたアプリケーションにも以下のコマンドを使用できます。
マスターノード内で、次のコマンドを実行して、 `+ nginx +`という名前のデプロイメントを作成します。
kubectl create deployment --image=デプロイメントはKubernetesオブジェクトの一種で、クラスターの存続期間中にポッドがクラッシュした場合でも、定義されたテンプレートに基づいて、指定された数のポッドが常に実行されるようにします。 上記の展開により、Dockerレジストリのhttps://hub.docker.com/_/nginx/[Nginx Docker Image]から1つのコンテナを持つポッドが作成されます。
次に、次のコマンドを実行して、アプリを公開する `+ nginx +`という名前のサービスを作成します。 これは、クラスターの各ノードで開かれた任意のポートを介してポッドにアクセスできるようにするスキームである_NodePort_を介して行われます。
kubectl expose deploy --port --target-port --type NodePortサービスは、クラスター内部サービスを内部および外部の両方のクライアントに公開する別の種類のKubernetesオブジェクトです。 また、複数のポッドへのリクエストの負荷分散が可能で、Kubernetesの不可欠なコンポーネントであり、他のコンポーネントと頻繁にやり取りします。
次のコマンドを実行してください。
kubectl get servicesこれにより、次のようなテキストが出力されます。
OutputNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d
NodePort 10.109.228.209 <none> 80:/TCP 40m上記の出力の3行目から、Nginxが実行されているポートを取得できます。 Kubernetesは、ポートが別のサービスによって既にバインドされていないことを確認しながら、「+ 30000+」より大きいランダムポートを自動的に割り当てます。
すべてが機能していることをテストするには、ローカルマシンのブラウザから `+ http：//：`または ` http：//：+`にアクセスします。 Nginxの使い慣れたウェルカムページが表示されます。
Nginxアプリケーションを削除する場合は、最初にマスターノードから `+ nginx +`サービスを削除します。
kubectl delete service次を実行して、サービスが削除されたことを確認します。
kubectl get services次の出力が表示されます。
OutputNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d次に、デプロイメントを削除します。
kubectl delete deployment以下を実行して、これが機能したことを確認します。
kubectl get deploymentsOutputNo resources found.結論
このガイドでは、KubeadmとAnsible for automationを使用して、Debian 9でKubernetesクラスターを正常にセットアップしました。
クラスターがセットアップされたので、クラスターで何をすべきか疑問に思っている場合は、次のステップとして、クラスターに独自のアプリケーションとサービスを快適にデプロイすることです。 プロセスのガイドとなる詳細情報を含むリンクのリストを次に示します。
-
https://docs.docker.com/engine/examples/ [アプリケーションのDockerizing]-Dockerを使用してアプリケーションをコンテナ化する方法を詳しく説明した例をリストします。
-
Pod Overview-Podがどのように機能するか、および他のKubernetesオブジェクトとの関係について詳しく説明します。 ポッドはKubernetesのいたるところにあるため、それらを理解すると作業が容易になります。
-
Deployments Overview-展開の概要を提供します。 デプロイメントなどのコントローラーは、スケーリングや不健全なアプリケーションの自動ヒーリングのためにステートレスアプリケーションで頻繁に使用されるため、どのように機能するかを理解しておくと役立ちます。
-
https://kubernetes.io/docs/concepts/services-networking/service/ [サービスの概要]-Kubernetesクラスターで頻繁に使用されるもう1つのオブジェクトであるサービスについて説明します。 ステートレスアプリケーションとステートフルアプリケーションの両方を実行するには、サービスのタイプとそのオプションを理解することが不可欠です。
確認できるその他の重要な概念は、https：//kubernetes.io/docs/concepts/storage/volumes/ [Volumes]、https：//kubernetes.io/docs/concepts/services-networking/ingress/ [Ingresses]です。およびhttps://kubernetes.io/docs/concepts/configuration/secret/[Secrets]。これらはすべて、実稼働アプリケーションをデプロイするときに役立ちます。
Kubernetesには、提供する多くの機能と機能があります。 The Kubernetes Official Documentationは、概念について学習し、タスク固有のガイドを見つけ、さまざまなオブジェクトのAPIリファレンスを検索するのに最適な場所です。