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

著者は、Write for DOnationsプログラムの一部として寄付を受け取るためにFree and Open Source Fundを選択しました。

前書き

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

[.note]#Note:このチュートリアルでは、この記事の公開時点でサポートされている公式バージョンであるバージョン1.14のKubernetesを使用しています。 最新バージョンの最新情報については、Kubernetesの公式ドキュメントのcurrent release notesを参照してください。

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

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

目標

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

  • 1つのマスターノード

マスターノード(Kubernetesのnodeはサーバーを指します)は、クラスターの状態を管理する役割を果たします。 Etcdを実行し、ワークロードをワーカーノードにスケジュールするコンポーネント間でクラスターデータを格納します。

  • 2つのワーカーノード

ワーカーノードは、workloadsが存在するサーバーです(つまり、 コンテナ化されたアプリケーションとサービス)が実行されます。 ワーカーは、スケジューリングが完了するとマスターがダウンしても、割り当てられたワークロードを引き続き実行します。 ワーカーを追加すると、クラスターの容量を増やすことができます。

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

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

前提条件

  • ローカルLinux / Mac OS / BSDマシン上のSSHキーペア。 これまでSSHキーを使用したことがない場合は、this explanation of how to set up SSH keys on your local machineに従ってSSHキーを設定する方法を学ぶことができます。

  • 少なくとも2GBのRAMとそれぞれ2つのvCPUを備えたUbuntu 16.04を実行する3つのサーバー。 SSHキーペアを使用して、rootユーザーとして各サーバーにSSH接続できるはずです。

  • ローカルマシンにインストールされたAnsible。 OSとしてUbuntu16.04を実行している場合は、How to Install and Configure Ansible on Ubuntu 16.04の「ステップ1-Ansibleのインストール」セクションに従ってAnsibleをインストールします。 Mac OS XやCentOSなどの他のプラットフォームでのインストール手順については、official Ansible installation documentationに従ってください。

  • Ansibleプレイブックに精通している。 レビューについては、Configuration Management 101: Writing Ansible Playbooksを確認してください。

  • Dockerイメージからコンテナーを起動する方法に関する知識。 復習が必要な場合は、How To Install and Use Docker on Ubuntu 16.04の「ステップ5 — Dockerコンテナーの実行」を参照してください。

[[step-1 -—- setting-up-the-workspace-directory-and-ansible-inventory-file]] ==ステップ1—ワークスペースディレクトリとAnsibleインベントリファイルの設定

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

3つのサーバーのうち、1つはIPがmaster_ipとして表示されるマスターになります。 他の2つのサーバーはワーカーであり、IPはworker_1_ipworker_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=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のinventory filesは、IPアドレス、リモートユーザー、コマンドを実行するための単一のユニットとしてターゲットとするサーバーのグループなどのサーバー情報を指定するために使用されることを思い出してください。 ~/kube-cluster/hostsがインベントリファイルになり、クラスターの論理構造を指定する2つのAnsibleグループ(mastersworkers)を追加しました。

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

同様に、workersグループには、ワーカーサーバー用の2つのエントリ(worker_1_ipworker_2_ip)があり、これらもansible_userをrootとして指定します。

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

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

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

[[step-2 -—- creating-a-non-root-user-on-all-remote-servers]] ==ステップ2—すべてのリモートサーバーで非rootユーザーを作成する

このセクションでは、すべてのサーバーで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 'ubuntu' user
      user: name=ubuntu append=yes state=present createhome=yes shell=/bin/bash

    - name: allow 'ubuntu' to have passwordless sudo
      lineinfile:
        dest: /etc/sudoers
        line: 'ubuntu ALL=(ALL) NOPASSWD: ALL'
        validate: 'visudo -cf %s'

    - name: set up authorized keys for the ubuntu user
      authorized_key: user=ubuntu key="{{item}}"
      with_file:
        - ~/.ssh/id_rsa.pub

このプレイブックの機能の内訳は次のとおりです。

  • 非rootユーザーubuntuを作成します。

  • ubuntuユーザーがパスワードプロンプトなしでsudoコマンドを実行できるようにsudoersファイルを構成します。

  • ローカルマシンの公開鍵(通常は~/.ssh/id_rsa.pub)をリモートのubuntuユーザーの許可鍵リストに追加します。 これにより、ubuntuユーザーとして各サーバーに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 'ubuntu' user] ****
changed: [master]
changed: [worker1]
changed: [worker2]

TASK [allow 'ubuntu' user to have passwordless sudo] ****
changed: [master]
changed: [worker1]
changed: [worker2]

TASK [set up authorized keys for the ubuntu 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固有の依存関係のインストールに進むことができます。

[[step-3 -—- installing-kubernetes-39-dependencies]] ==ステップ3—Kubernetesの依存関係をインストールする

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

  • 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 Docker
     apt:
       name: docker.io
       state: present
       update_cache: true

   - name: install APT Transport HTTPS
     apt:
       name: apt-transport-https
       state: present

   - 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-transport-httpsをインストールし、外部HTTPSソースをAPTソースリストに追加できるようにします。

  • キー検証のためにKubernetes APTリポジトリのapt-keyを追加します。

  • Kubernetes APTリポジトリをリモートサーバーのAPTソースリストに追加します。

  • kubeletおよびkubeadmをインストールします。

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

[.note]#Note: 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コマンドは、任意のワーカーノードから、またはクラスターを指すようにインストールおよび構成できる任意のマシンから実行できることに注意してください。

これで、すべてのシステム依存関係がインストールされました。 マスターノードをセットアップして、クラスターを初期化しましょう。

[[step-4 -—- setting-up-the-master-node]] ==ステップ4—マスターノードのセットアップ

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

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

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

この機能は、ポッドネットワークプラグインによって提供されます。 このクラスターでは、安定したパフォーマンスの高いオプションである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: ubuntu
      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/ubuntu/.kube/config
        remote_src: yes
        owner: ubuntu

    - name: install Pod network
      become: yes
      become_user: ubuntu
      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番目のタスクは、/home/ubuntu.kubeディレクトリを作成します。 このディレクトリには、クラスターへの接続に必要な管理キーファイルやクラスターのAPIアドレスなどの構成情報が保持されます。

  • 3番目のタスクは、kubeadm initから生成された/etc/kubernetes/admin.confファイルをroot以外のユーザーのホームディレクトリにコピーします。 これにより、kubectlを使用して新しく作成されたクラスターにアクセスできます。

  • 最後のタスクはkubectl applyを実行してFlannelをインストールします。 kubectl apply -f descriptor.[yml|json]は、descriptor.[yml|json]ファイルに記述されているオブジェクトを作成するようにkubectlに指示するための構文です。 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でマスターノードに接続します。

マスターノード内で、次を実行します。

kubectl get nodes

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

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

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

[[step-5 -—- setting-up-the-worker-nodes]] ==ステップ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コマンドを取得します。 このコマンドの形式は次のとおりです。`kubeadmjoin--token --discovery-token-ca-cert-hash sha256: `。 適切なtokenhashの値を持つ実際のコマンドを取得すると、タスクはそれをファクトとして設定し、次のプレイがその情報にアクセスできるようにします。

  • 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

ワーカーノードを追加すると、クラスターが完全にセットアップされて機能するようになり、ワーカーはワークロードを実行する準備が整います。 アプリケーションをスケジュールする前に、クラスターが意図したとおりに機能していることを確認しましょう。

[[step-6 -—- verifying-the-cluster]] ==ステップ6—クラスターの検証

ノードがダウンしているか、マスターとワーカー間のネットワーク接続が正しく機能していないため、セットアップ中にクラスターが失敗することがあります。 クラスターを検証し、ノードが正しく動作していることを確認しましょう。

マスターノードからクラスターの現在の状態をチェックして、ノードの準備ができていることを確認する必要があります。 マスターノードから切断した場合、次のコマンドを使用してSSHでマスターノードに戻すことができます。

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

kubectl get nodes

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

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

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

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

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

[[step-7 -—- running-an-application-on-the-cluster]] ==ステップ7—クラスターでのアプリケーションの実行

これで、コンテナ化されたアプリケーションをクラスターにデプロイできます。 慣れるために、DeploymentsServicesを使用してNginxをデプロイし、このアプリケーションをクラスターにデプロイする方法を確認しましょう。 Dockerイメージ名と関連するフラグ(portsvolumesなど)を変更すれば、他のコンテナー化されたアプリケーションにも以下のコマンドを使用できます。

マスターノード内で、次のコマンドを実行して、nginxという名前のデプロイメントを作成します。

kubectl create deployment nginx --image=nginx

デプロイメントはKubernetesオブジェクトの一種で、クラスターの存続期間中にポッドがクラッシュした場合でも、定義されたテンプレートに基づいて、指定された数のポッドが常に実行されるようにします。 上記のデプロイでは、DockerレジストリのNginx Docker Imageから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                        443/TCP        1d
nginx        NodePort    10.109.228.209                   80:nginx_port/TCP   40m

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

すべてが機能していることをテストするには、ローカルマシンのブラウザから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                        443/TCP        1d

次に、デプロイメントを削除します。

kubectl delete deployment nginx

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

kubectl get deployments
OutputNo resources found.

結論

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

クラスターがセットアップされたので、クラスターで何をすべきか疑問に思っている場合は、次のステップとして、クラスターに独自のアプリケーションとサービスを快適にデプロイすることです。 プロセスのガイドとなる詳細情報を含むリンクのリストを次に示します。

  • Dockerizing applications-Dockerを使用してアプリケーションをコンテナー化する方法を詳しく説明する例を示します。

  • Pod Overview-ポッドがどのように機能し、他のKubernetesオブジェクトとの関係を詳細に説明します。 ポッドはKubernetesに遍在しているため、それらを理解すると作業が容易になります。

  • Deployments Overview-これは展開の概要を提供します。 デプロイメントなどのコントローラーは、スケーリングや不健全なアプリケーションの自動ヒーリングのためにステートレスアプリケーションで頻繁に使用されるため、どのように機能するかを理解しておくと役立ちます。

  • Services Overview-これは、Kubernetesクラスターで頻繁に使用されるもう1つのオブジェクトであるサービスを対象としています。 ステートレスアプリケーションとステートフルアプリケーションの両方を実行するには、サービスのタイプとそのオプションを理解することが不可欠です。

調べることができる他の重要な概念は、VolumesIngresses、およびSecretsです。これらはすべて、実稼働アプリケーションをデプロイするときに役立ちます。

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

Related