Debian9でKubeadmを使用してKubernetesクラスタを作成する方法

投稿日: 2019-11-08 2022-10-17
タグ: Ansible, Debian 9, deployment, Docker, Kubernetes, nginx

序章

Kubernetes は、コンテナーを大規模に管理するコンテナーオーケストレーションシステムです。 Kubernetesは、本番環境でコンテナを実行した経験に基づいてGoogleが最初に開発したもので、オープンソースであり、世界中のコミュニティによって積極的に開発されています。

注：このチュートリアルでは、この記事の公開時点でサポートされている公式バージョンであるバージョン1.14のKubernetesを使用しています。最新バージョンの最新情報については、Kubernetesの公式ドキュメントの最新リリースノートを参照してください。

Kubeadm は、APIサーバー、コントローラーマネージャー、KubeDNSなどのKubernetesコンポーネントのインストールと構成を自動化します。ただし、ユーザーを作成したり、オペレーティングシステムレベルの依存関係のインストールとその構成を処理したりすることはありません。これらの予備的なタスクには、AnsibleやSaltStackなどの構成管理ツールを使用できます。これらのツールを使用すると、追加のクラスターの作成や既存のクラスターの再作成がはるかに簡単になり、エラーが発生しにくくなります。

このガイドでは、AnsibleとKubeadmを使用してKubernetesクラスターを最初からセットアップし、コンテナー化されたNginxアプリケーションをデプロイします。

目標

クラスタには、次の物理リソースが含まれます。

1つのマスターノード

マスターノード（Kubernetesの node はサーバーを指します）は、クラスターの状態を管理する責任があります。 Etcd を実行し、ワーカーノードへのワークロードをスケジュールするコンポーネント間でクラスターデータを格納します。
2つのワーカーノード

ワーカーノードは、ワークロード（つまりコンテナ化されたアプリケーションとサービス）が実行されます。ワーカーは、割り当てられた後もワークロードを実行し続けます。スケジュールが完了するとマスターがダウンした場合でも同様です。ワーカーを追加することで、クラスターの容量を増やすことができます。

このガイドを完了すると、クラスター内のサーバーにアプリケーションが消費するのに十分なCPUおよびRAMリソースがあれば、コンテナー化されたアプリケーションを実行する準備が整います。 Webアプリケーション、データベース、デーモン、コマンドラインツールなど、ほとんどすべての従来のUnixアプリケーションをコンテナ化して、クラスタで実行することができます。クラスタ自体は、各ノードで約300〜500MBのメモリと10% ofのCPUを消費します。

クラスターをセットアップしたら、Webサーバー Nginx をクラスターにデプロイして、ワークロードが正しく実行されていることを確認します。

前提条件

ローカルのLinux/macOS/BSDマシン上のSSHキーペア。これまでにSSHキーを使用したことがない場合は、ローカルマシンでのSSHキーの設定方法の説明に従って、SSHキーの設定方法を学ぶことができます。
それぞれ少なくとも2GBのRAMと2つのvCPUを備えたDebian9を実行している3台のサーバー。 SSHキーペアを使用してrootユーザーとして各サーバーにSSHで接続できる必要があります。
Ansibleがローカルマシンにインストールされています。インストール手順については、公式のAnsibleインストールドキュメントに従ってください。
Ansibleプレイブックに精通していること。レビューについては、 Configuration Management 101：Writing AnsiblePlaybooksをご覧ください。
Dockerイメージからコンテナーを起動する方法に関する知識。復習が必要な場合は、 Debian 9にDockerをインストールして使用する方法の「ステップ5—Dockerコンテナの実行」を参照してください。

ステップ1—ワークスペースディレクトリとAnsibleインベントリファイルを設定する

このセクションでは、ワークスペースとして機能するディレクトリをローカルマシンに作成します。 Ansibleをローカルで構成して、リモートサーバーと通信してコマンドを実行できるようにします。それが完了したら、作成します hosts サーバーのIPアドレスや各サーバーが属するグループなどのインベントリ情報を含むファイル。

3台のサーバーのうち、1台はIPが次のように表示されるマスターになります master_ip. 他の2つのサーバーはワーカーであり、IPを持ちます worker_1_ip と worker_2_ip.

という名前のディレクトリを作成します ~/kube-cluster ローカルマシンのホームディレクトリにあり、 cd それに：

mkdir ~/kube-cluster
cd ~/kube-cluster

このディレクトリは、チュートリアルの残りの部分のワークスペースになり、すべてのAnsibleプレイブックが含まれます。また、すべてのローカルコマンドを実行するディレクトリにもなります。

名前の付いたファイルを作成します ~/kube-cluster/hosts を使用して nano またはお気に入りのテキストエディタ：

nano ~/kube-cluster/hosts

次のテキストをファイルに追加します。これにより、クラスターの論理構造に関する情報が指定されます。

〜/ kube-cluster / hosts

[masters]
master ansible_host=master_ip ansible_user=root

[workers]
worker1 ansible_host=worker_1_ip ansible_user=root
worker2 ansible_host=worker_2_ip ansible_user=root

[all:vars]
ansible_python_interpreter=/usr/bin/python3

Ansibleのインベントリファイルは、コマンドを実行するための単一のユニットとしてターゲットとするIPアドレス、リモートユーザー、サーバーのグループなどのサーバー情報を指定するために使用されることを思い出してください。 ~/kube-cluster/hosts インベントリファイルになり、クラスターの論理構造を指定する2つのAnsibleグループ（mastersとworkers）を追加しました。

masters グループには、マスターノードのIPを一覧表示する「master」という名前のサーバーエントリがあります（master_ip）そして、Ansibleがrootユーザーとしてリモートコマンドを実行する必要があることを指定します。

同様に、 workers グループには、ワーカーサーバー用の2つのエントリがあります（worker_1_ip と worker_2_ip）も指定します ansible_user ルートとして。

ファイルの最後の行は、AnsibleにリモートサーバーのPython3インタープリターを管理操作に使用するように指示しています。

テキストを追加したら、ファイルを保存して閉じます。

グループを使用してサーバーインベントリを設定したら、オペレーティングシステムレベルの依存関係のインストールと構成設定の作成に進みましょう。

手順2—すべてのリモートサーバーでroot以外のユーザーを作成する

このセクションでは、すべてのサーバーでsudo権限を持つ非rootユーザーを作成し、非特権ユーザーとして手動でサーバーにSSH接続できるようにします。これは、たとえば、次のようなコマンドでシステム情報を表示したい場合に役立ちます。 top/htop、実行中のコンテナのリストを表示するか、rootが所有する構成ファイルを変更します。これらの操作はクラスターの保守中に日常的に実行され、そのようなタスクにroot以外のユーザーを使用すると、重要なファイルを変更または削除したり、意図せずに他の危険な操作を実行したりするリスクを最小限に抑えることができます。

名前の付いたファイルを作成します ~/kube-cluster/initial.yml ワークスペース内：

nano ~/kube-cluster/initial.yml

次に、次の play をファイルに追加して、すべてのサーバーでsudo権限を持つ非rootユーザーを作成します。 Ansibleでのプレイは、特定のサーバーとグループを対象として実行されるステップのコレクションです。次の再生では、root以外の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.
を構成します sudoers 許可するファイル sammy 実行するユーザー sudo パスワードプロンプトなしのコマンド。
ローカルマシンに公開鍵を追加します（通常は ~/.ssh/id_rsa.pub）リモートへ sammy ユーザーの許可されたキーリスト。これにより、各サーバーにSSHで接続できるようになります。 sammy ユーザー。

テキストを追加したら、ファイルを保存して閉じます。

次に、ローカルで実行してプレイブックを実行します。

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の依存関係をインストールする

このセクションでは、Kubernetesに必要なオペレーティングシステムレベルのパッケージをDebianのパッケージマネージャーとともにインストールします。これらのパッケージは次のとおりです。

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

プレイブックの最初のプレイは次のことを行います。

リモートリポジトリからパッケージを追加、検証、およびインストールするための依存関係を追加します。
キー検証用のDockerAPTリポジトリのapt-keyを追加します。
コンテナランタイムであるDockerをインストールします。
キー検証用にKubernetesAPTリポジトリのapt-keyを追加します。
KubernetesAPTリポジトリをリモートサーバーのAPTソースリストに追加します。
インストール kubelet と kubeadm.

2番目のプレイは、インストールする単一のタスクで構成されます kubectl マスターノードで。

注： Kubernetesのドキュメントでは、ご使用の環境に最新の安定したリリースのKubernetesを使用することを推奨していますが、このチュートリアルでは特定のバージョンを使用しています。これにより、Kubernetesは急速に変化し、最新バージョンがこのチュートリアルで機能しない可能性があるため、手順を正常に実行できるようになります。

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

次に、ローカルで実行してプレイブックを実行します。

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—マスターノードのセットアップ

このセクションでは、マスターノードを設定します。ただし、プレイブックを作成する前に、クラスターに両方が含まれるため、ポッドやポッドネットワークプラグインなどのいくつかの概念を説明する価値があります。

ポッドは、1つ以上のコンテナを実行するアトミックユニットです。これらのコンテナは、ファイルボリュームやネットワークインターフェイスなどのリソースを共有します。ポッドはKubernetesのスケジューリングの基本単位です。ポッド内のすべてのコンテナは、ポッドがスケジュールされているのと同じノードで実行されることが保証されています。

各ポッドには独自のIPアドレスがあり、あるノードのポッドは、ポッドのIPを使用して別のノードのポッドにアクセスできる必要があります。単一ノード上のコンテナは、ローカルインターフェイスを介して簡単に通信できます。ただし、ポッド間の通信はより複雑であり、あるノードのポッドから別のノードのポッドにトラフィックを透過的にルーティングできる別個のネットワークコンポーネントが必要です。

この機能は、ポッドネットワークプラグインによって提供されます。このクラスターでは、安定したパフォーマンスの高いオプションであるフランネルを使用します。

名前の付いたAnsibleプレイブックを作成する master.yml ローカルマシン上：

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が割り当てられるプライベートサブネットを指定します。 Flannelは、デフォルトで上記のサブネットを使用します。私たちは言っています kubeadm 同じサブネットを使用します。
2番目のタスクは .kube のディレクトリ /home/sammy. このディレクトリには、クラスタへの接続に必要な管理キーファイルやクラスタのAPIアドレスなどの構成情報が保持されます。
3番目のタスクは /etc/kubernetes/admin.conf から生成されたファイル kubeadm init root以外のユーザーのホームディレクトリに移動します。これにより、 kubectl 新しく作成されたクラスターにアクセスします。
最後のタスクが実行されます kubectl apply インストールする Flannel. kubectl apply -f descriptor.[yml|json] 伝えるための構文です kubectl で説明されているオブジェクトを作成するには descriptor.[yml|json] ファイル。 The 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@master_ip

マスターノード内に入ったら、次を実行します。

kubectl get nodes

次の出力が表示されます。

OutputNAME      STATUS    ROLES     AGE       VERSION
master    Ready     master    1d        v1.14.0

出力には、 master ノードはすべての初期化タスクを完了し、 Ready ワーカーノードの受け入れとAPIサーバーに送信されたタスクの実行を開始できる状態。これで、ローカルマシンからワーカーを追加できます。

ステップ5—ワーカーノードを設定する

クラスタにワーカーを追加するには、それぞれに対して1つのコマンドを実行する必要があります。このコマンドには、マスターの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>. 適切なトークンおよびハッシュ値を持つ実際のコマンドを取得すると、タスクはそれをファクトとして設定し、次のプレイがその情報にアクセスできるようにします。
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@master_ip

次に、次のコマンドを実行して、クラスターのステータスを取得します。

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

すべてのノードに値がある場合 Ready 為に STATUS、それはそれらがクラスターの一部であり、ワークロードを実行する準備ができていることを意味します。

ただし、いくつかのノードに NotReady として STATUS、ワーカーノードがまだセットアップを完了していないことを意味している可能性があります。再実行する前に、約5〜10分待ちます kubectl get nodes 新しい出力を検査します。いくつかのノードがまだ持っている場合 NotReady ステータスとして、前の手順でコマンドを確認して再実行する必要がある場合があります。

クラスタが正常に検証されたので、クラスタでサンプルのNginxアプリケーションをスケジュールしましょう。

ステップ7—クラスターでのアプリケーションの実行

これで、コンテナー化されたアプリケーションをクラスターにデプロイできます。慣れるために、DeploymentsとServicesを使用してNginxをデプロイし、このアプリケーションをクラスターにデプロイする方法を確認しましょう。 Dockerイメージ名と関連するフラグ（たとえば、 ports と volumes).

マスターノード内で、次のコマンドを実行して、 nginx:

kubectl create deployment nginx --image=nginx

デプロイはKubernetesオブジェクトの一種であり、クラスターの存続期間中にポッドがクラッシュした場合でも、定義されたテンプレートに基づいて指定された数のポッドが常に実行されるようにします。上記のデプロイでは、Dockerレジストリの Nginx DockerImageから1つのコンテナーでポッドが作成されます。

次に、次のコマンドを実行して、という名前のサービスを作成します nginx これにより、アプリが公開されます。これは、 NodePort を介して行われます。これは、クラスターの各ノードで開かれた任意のポートを介してポッドにアクセスできるようにするスキームです。

kubectl expose deploy nginx --port 80 --target-port 80 --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
nginx        NodePort    10.109.228.209   <none>                80:nginx_port/TCP   40m

上記の出力の3行目から、Nginxが実行されているポートを取得できます。 Kubernetesは、より大きいランダムポートを割り当てます 30000 ポートが別のサービスによってまだバインドされていないことを確認しながら、自動的に。

すべてが機能していることをテストするには、次のWebサイトにアクセスしてください。 http://worker_1_ip:nginx_port また http://worker_2_ip:nginx_port ローカルマシンのブラウザを介して。 Nginxのおなじみのウェルカムページが表示されます。

Nginxアプリケーションを削除する場合は、最初に nginx マスターノードからのサービス：

kubectl delete service nginx

以下を実行して、サービスが削除されたことを確認します。

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 nginx

以下を実行して、これが機能したことを確認します。

kubectl get deployments

OutputNo resources found.

結論

このガイドでは、自動化にKubeadmとAnsibleを使用して、Debian9でKubernetesクラスターを正常にセットアップしました。

セットアップが完了したクラスターをどうするか迷っている場合は、次のステップとして、独自のアプリケーションとサービスをクラスターに快適にデプロイできるようにすることをお勧めします。プロセスをガイドするための詳細情報を含むリンクのリストは次のとおりです。

アプリケーションのDocker化-Dockerを使用してアプリケーションをコンテナ化する方法の詳細を示す例を示します。
ポッドの概要-ポッドがどのように機能するか、および他のKubernetesオブジェクトとの関係について詳しく説明します。ポッドはKubernetesに遍在しているため、ポッドを理解すると作業が容易になります。
デプロイメントの概要-デプロイメントの概要を提供します。デプロイメントなどのコントローラーは、スケーリングや異常なアプリケーションの自動修復のためにステートレスアプリケーションで頻繁に使用されるため、どのように機能するかを理解しておくと便利です。
サービスの概要-Kubernetesクラスターで頻繁に使用されるもう1つのオブジェクトであるサービスについて説明します。サービスの種類とそのオプションを理解することは、ステートレスアプリケーションとステートフルアプリケーションの両方を実行するために不可欠です。

調べることができるその他の重要な概念は、ボリューム、イングレス、およびシークレットです。これらはすべて、実稼働アプリケーションをデプロイするときに役立ちます。

Kubernetesには多くの機能と機能があります。 Kubernetes公式ドキュメントは、概念について学び、タスク固有のガイドを見つけ、さまざまなオブジェクトのAPIリファレンスを検索するのに最適な場所です。

getdocs

13036