開発者ドキュメント

Ubuntu18.04でKubeadmを使用してKubernetesクラスターを作成する方法

序章

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

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

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

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

目標

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

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

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

前提条件

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

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

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

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

  1. mkdir ~/kube-cluster
  2. cd ~/kube-cluster

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

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

  1. 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グループ(mastersworkers)を追加しました。

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

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

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

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

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

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

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

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

  1. nano ~/kube-cluster/initial.yml

次に、次の play をファイルに追加して、すべてのサーバーでsudo権限を持つ非rootユーザーを作成します。 Ansibleでのプレイは、特定のサーバーとグループを対象として実行されるステップのコレクションです。 次の再生では、root以外の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

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

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

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

  1. ansible-playbook -i hosts ~/kube-cluster/initial.yml

コマンドは2〜5分以内に完了します。 完了すると、次のような出力が表示されます。

Output
PLAY [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固有の依存関係のインストールに進むことができます。

ステップ3—Kubernetetesの依存関係をインストールする

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

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

  1. 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

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

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

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

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

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

  1. ansible-playbook -i hosts ~/kube-cluster/kube-dependencies.yml

完了すると、次のような出力が表示されます。

Output
PLAY [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 ローカルマシン上:

  1. 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

このプレイの内訳は次のとおりです。

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

次のコマンドを実行して、プレイブックをローカルで実行します。

  1. 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で接続します。

  1. ssh ubuntu@master_ip

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

  1. kubectl get nodes

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

Output
NAME STATUS ROLES AGE VERSION master Ready master 1d v1.14.0

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

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

クラスタにワーカーを追加するには、それぞれに対して1つのコマンドを実行する必要があります。 このコマンドには、マスターのAPIサーバーのIPアドレスやポート、セキュアトークンなどの必要なクラスター情報が含まれています。 セキュアトークンを渡すノードのみがクラスターに参加できます。

ワークスペースに戻り、という名前のプレイブックを作成します workers.yml:

  1. 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

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

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

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

  1. ansible-playbook -i hosts ~/kube-cluster/workers.yml

完了すると、次のような出力が表示されます。

Output
PLAY [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で戻すことができます。

  1. ssh ubuntu@master_ip

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

  1. kubectl get nodes

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

Output
NAME 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—クラスターでのアプリケーションの実行

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

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

  1. kubectl create deployment nginx --image=nginx

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

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

  1. kubectl expose deploy nginx --port 80 --target-port 80 --type NodePort

サービスは、クラスター内部サービスを内部と外部の両方のクライアントに公開する別のタイプのKubernetesオブジェクトです。 また、複数のポッドへのリクエストの負荷分散も可能であり、Kubernetesの不可欠なコンポーネントであり、他のコンポーネントと頻繁にやり取りします。

次のコマンドを実行します。

  1. kubectl get services

これにより、次のようなテキストが出力されます。

Output
NAME 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 マスターノードからのサービス:

  1. kubectl delete service nginx

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

  1. kubectl get services

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

Output
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 1d

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

  1. kubectl delete deployment nginx

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

  1. kubectl get deployments
Output
No resources found.

結論

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

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

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

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

モバイルバージョンを終了