クラスター内アプリケーションへのアクセス

• 1: Web UI (Dashboard)
• 2: 複数のクラスターへのアクセスを設定する
• 3: クラスター内のアプリケーションにアクセスするためにポートフォワーディングを使用する
• 4: Serviceを利用したクラスター内のアプリケーションへのアクセス
• 5: Serviceを使用してフロントエンドをバックエンドに接続する
• 6: 外部ロードバランサーを作成する
• 7: クラスターで実行されているすべてのコンテナイメージを一覧表示する
• 8: Minikube上でNGINX Ingressコントローラーを使用してIngressをセットアップする
• 9: 共有ボリュームを使用して同じPod内のコンテナ間で通信する
• 10: クラスターのDNSを設定する

1 - Web UI (Dashboard)

ダッシュボードは、WebベースのKubernetesユーザーインターフェースです。 ダッシュボードを使用して、コンテナ化されたアプリケーションをKubernetesクラスターにデプロイしたり、 コンテナ化されたアプリケーションをトラブルシューティングしたり、クラスターリソースを管理したりすることができます。 ダッシュボードを使用して、クラスター上で実行されているアプリケーションの概要を把握したり、 個々のKubernetesリソース(Deployments、Jobs、DaemonSetsなど)を作成または修正したりすることができます。 たとえば、Deploymentのスケール、ローリングアップデートの開始、Podの再起動、 デプロイウィザードを使用した新しいアプリケーションのデプロイなどが可能です。

ダッシュボードでは、クラスター内のKubernetesリソースの状態や、発生した可能性のあるエラーに関する情報も提供されます。

ダッシュボードUIのデプロイ

ダッシュボードUIはデフォルトではデプロイされていません。デプロイするには、以下のコマンドを実行します:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml

ダッシュボードUIへのアクセス

クラスターデータを保護するために、ダッシュボードはデフォルトで最小限のRBAC構成でデプロイします。 現在、ダッシュボードはBearer Tokenによるログインのみをサポートしています。 このデモ用のトークンを作成するには、 サンプルユーザーの作成ガイドに従ってください。

コマンドラインプロキシ

以下のコマンドを実行することで、kubectlコマンドラインツールを使ってダッシュボードにアクセスすることができます:

kubectl proxy

kubectlは、ダッシュボードを http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ で利用できるようにします。

UIはコマンドを実行しているマシンから のみ アクセスできます。オプションについてはkubectl proxy --helpを参照してください。

ウェルカムビュー

空のクラスターでダッシュボードにアクセスすると、ウェルカムページが表示されます。 このページには、このドキュメントへのリンクと、最初のアプリケーションをデプロイするためのボタンが含まれています。 さらに、クラスターのkube-system名前空間でデフォルトで実行されているシステムアプリケーション、たとえばダッシュボード自体を見ることができます。

コンテナ化されたアプリケーションのデプロイ

ダッシュボードを使用すると、簡単なウィザードでコンテナ化されたアプリケーションをDeploymentとオプションのServiceとして作成してデプロイすることができます。 アプリケーションの詳細を手動で指定するか、アプリケーションの設定を含むYAMLまたはJSONファイルをアップロードすることができます。

任意のページの右上にあるCREATEボタンをクリックして開始します。

アプリケーションの詳細の指定

デプロイウィザードでは、以下の情報を入力する必要があります:

• App name (必須): アプリケーションの名前です。 その名前のlabelは、デプロイされるDeploymentとServiceに追加されます。

  アプリケーション名は、選択したKubernetes名前空間内で一意である必要があります。 小文字で始まり、小文字または数字で終わり、小文字、数字、ダッシュ(-)のみを含む必要があります。文字数は24文字に制限されています。先頭と末尾のスペースは無視されます。

• Container image (必須): 任意のレジストリ上の公開Dockerコンテナイメージ、またはプライベートイメージ(一般的にはGoogle Container RegistryやDocker Hub上でホストされている)のURLです。 コンテナイメージの指定はコロンで終わらせる必要があります。

  クラスター全体で必要な数のPodを維持するために、Deploymentが作成されます。

• Service (任意): アプリケーションのいくつかの部分(たとえばフロントエンド)では、 Serviceをクラスター外の外部、おそらくパブリックIPアドレス(外部サービス)に公開したいと思うかもしれません。

  備考:

  外部サービスの場合は、そのために1つ以上のポートを開放する必要があるでしょう。

  クラスター内部からしか見えないその他のサービスは、内部サービスと呼ばれます。

  サービスの種類にかかわらず、サービスを作成し、コンテナがポート(受信)をリッスンする場合は、 2つのポートを指定する必要があります。 サービスは、ポート(受信)をコンテナから見たターゲットポートにマッピングして作成されます。 このサービスは、デプロイされたPodにルーティングされます。サポートされるプロトコルはTCPとUDPです。 このサービスの内部DNS名は、上記のアプリケーション名として指定した値になります。

必要に応じて、高度なオプションセクションを展開して、より多くの設定を指定することができます:

• Description: ここで入力したテキストは、 アノテーションとしてDeploymentに追加され、アプリケーションの詳細に表示されます。

• Labels: アプリケーションに使用するデフォルトのラベルは、アプリケーション名とバージョンです。 リリース、環境、ティア、パーティション、リリーストラックなど、Deployment、Service(存在する場合)、Podに適用する追加のラベルを指定できます。

  例:

  release=1.0
  tier=frontend
  environment=pod
  track=stable
  

• Namespace: Kubernetesは、同じ物理クラスターを基盤とする複数の仮想クラスターをサポートしています。 これらの仮想クラスターは名前空間 と呼ばれます。 これにより、リソースを論理的に名前のついたグループに分割することができます。

  ダッシュボードでは、利用可能なすべての名前空間がドロップダウンリストに表示され、新しい名前空間を作成することができます。 名前空間名には、最大63文字の英数字とダッシュ(-)を含めることができますが、大文字を含めることはできません。 名前空間名は数字だけで構成されるべきではありません。 名前が10などの数値として設定されている場合、Podはデフォルトの名前空間に配置されます。

  名前空間の作成に成功した場合は、デフォルトで選択されます。 作成に失敗した場合は、最初の名前空間が選択されます。

• Image Pull Secret: 指定されたDockerコンテナイメージが非公開の場合、 pull secretの認証情報が必要になる場合があります。

  ダッシュボードでは、利用可能なすべてのSecretがドロップダウンリストに表示され、新しいSecretを作成できます。 Secret名は DNSドメイン名の構文に従う必要があります。たとえば、new.image-pull.secretです。 Secretの内容はbase64エンコードされ、.dockercfgファイルで指定されている必要があります。 Secret名は最大253文字で構成されます。

  イメージプルシークレットの作成に成功した場合は、デフォルトで選択されています。作成に失敗した場合は、シークレットは適用されません。

• CPU requirement (cores)とMemory requirement (MiB): コンテナの最小リソース制限を指定することができます。デフォルトでは、PodはCPUとメモリの制限がない状態で実行されます。

• Run commandとRun command arguments: デフォルトでは、コンテナは指定されたDockerイメージのデフォルトのentrypointコマンドを実行します。 コマンドのオプションと引数を使ってデフォルトを上書きすることができます。

• Run as privileged: この設定は、特権コンテナ内のプロセスが、ホスト上でrootとして実行されているプロセスと同等であるかどうかを決定します。特権コンテナは、 ネットワークスタックの操作やデバイスへのアクセスなどの機能を利用できます。

• Environment variables: Kubernetesは環境変数を介してServiceを公開しています。 環境変数を作成したり、環境変数の値を使ってコマンドに引数を渡したりすることができます。 環境変数の値はServiceを見つけるためにアプリケーションで利用できます。 値は$(VAR_NAME)構文を使用して他の変数を参照できます。

YAMLまたはJSONファイルのアップロード

Kubernetesは宣言的な設定をサポートしています。 このスタイルでは、すべての設定は Kubernetes APIリソーススキーマを使用してYAMLまたは JSON設定ファイルに格納されます。

デプロイウィザードでアプリケーションの詳細を指定する代わりに、 YAMLまたはJSONファイルでアプリケーションを定義し、ダッシュボードを使用してファイルをアップロードできます。

ダッシュボードの使用

以下のセクションでは、Kubernetes Dashboard UIのビュー、それらが提供するものとその使用方法について説明します。

ナビゲーション

クラスターにKubernetesオブジェクトが定義されている場合、ダッシュボードではそれらのオブジェクトが初期表示されます。 デフォルトでは default 名前空間のオブジェクトのみが表示されますが、これはナビゲーションメニューにある名前空間セレクターで変更できます。

ダッシュボードにはほとんどのKubernetesオブジェクトの種類が表示され、いくつかのメニューカテゴリーにグループ化されています。

管理者の概要

クラスターと名前空間の管理者向けに、ダッシュボードにはノード、名前空間、永続ボリュームが一覧表示され、それらの詳細ビューが用意されています。 ノードリストビューには、すべてのノードにわたって集計されたCPUとメモリーのメトリクスが表示されます。 詳細ビューには、ノードのメトリクス、仕様、ステータス、割り当てられたリソース、イベント、ノード上で実行されているPodが表示されます。

ワークロード

選択した名前空間で実行されているすべてのアプリケーションを表示します。 このビューでは、アプリケーションがワークロードの種類(例：Deployment、ReplicaSet、StatefulSetなど)ごとに一覧表示され、各ワークロードの種類を個別に表示することができます。 リストには、ReplicaSetの準備ができたPodの数やPodの現在のメモリ使用量など、ワークロードに関する実用的な情報がまとめられています。

ワークロードの詳細ビューには、ステータスや仕様情報、オブジェクト間の表面関係が表示されます。 たとえば、ReplicaSetが制御しているPodや、新しいReplicaSet、DeploymentのためのHorizontal Pod Autoscalerなどです。

Service

外部の世界にサービスを公開し、クラスター内でサービスを発見できるようにするKubernetesリソースを表示します。 そのため、ServiceとIngressのビューには、それらが対象とするPod、クラスター接続の内部エンドポイント、外部ユーザーの外部エンドポイントが表示されます。

ストレージ

ストレージビューには、アプリケーションがデータを保存するために使用するPersistentVolumeClaimリソースが表示されます。

ConfigMapとSecret

クラスターで実行されているアプリケーションのライブ設定に使用されているすべてのKubernetesリソースを表示します。 このビューでは、設定オブジェクトの編集と管理が可能で、デフォルトで非表示になっているSecretを表示します。

ログビューアー

Podのリストと詳細ページは、ダッシュボードに組み込まれたログビューアーにリンクしています。 このビューアーでは、単一のPodに属するコンテナからログをドリルダウンすることができます。

次の項目

詳細についてはKubernetes Dashboardプロジェクトページをご覧ください。

2 - 複数のクラスターへのアクセスを設定する

ここでは、設定ファイルを使って複数のクラスターにアクセスする方法を紹介します。クラスター、ユーザー、コンテキストの情報を一つ以上の設定ファイルにまとめることで、kubectl config use-contextのコマンドを使ってクラスターを素早く切り替えることができます。

始める前に

Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

kubectlがインストールされているか確認するため、kubectl version --clientを実行してください。kubectlのバージョンは、クラスターのAPIサーバーの1つのマイナーバージョン内である必要があります。

クラスター、ユーザー、コンテキストを設定する

例として、開発用のクラスターが一つ、実験用のクラスターが一つ、計二つのクラスターが存在する場合を考えます。developmentと呼ばれる開発用のクラスター内では、フロントエンドの開発者はfrontendというnamespace内で、ストレージの開発者はstorageというnamespace内で作業をします。scratchと呼ばれる実験用のクラスター内では、開発者はデフォルトのnamespaceで作業をするか、状況に応じて追加のnamespaceを作成します。開発用のクラスターは証明書を通しての認証を必要とします。実験用のクラスターはユーザーネームとパスワードを通しての認証を必要とします。

config-exerciseというディレクトリを作成してください。config-exerciseディレクトリ内に、以下を含むconfig-demoというファイルを作成してください:

apiVersion: v1
kind: Config
preferences: {}

clusters:
- cluster:
  name: development
- cluster:
  name: scratch

users:
- name: developer
- name: experimenter

contexts:
- context:
  name: dev-frontend
- context:
  name: dev-storage
- context:
  name: exp-scratch

設定ファイルには、クラスター、ユーザー、コンテキストの情報が含まれています。上記のconfig-demo設定ファイルには、二つのクラスター、二人のユーザー、三つのコンテキストの情報が含まれています。

config-exerciseディレクトリに移動してください。クラスター情報を設定ファイルに追加するために、以下のコマンドを実行してください:

kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
kubectl config --kubeconfig=config-demo set-cluster scratch --server=https://5.6.7.8 --insecure-skip-tls-verify

ユーザー情報を設定ファイルに追加してください:

kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-seefile
kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password

コンテキスト情報を設定ファイルに追加してください:

kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter

追加した情報を確認するために、config-demoファイルを開いてください。config-demoファイルを開く代わりに、config viewのコマンドを使うこともできます。

kubectl config --kubeconfig=config-demo view

出力には、二つのクラスター、二人のユーザー、三つのコンテキストが表示されます:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
- cluster:
    insecure-skip-tls-verify: true
    server: https://5.6.7.8
  name: scratch
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: scratch
    namespace: default
    user: experimenter
  name: exp-scratch
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file
- name: experimenter
  user:
    password: some-password
    username: exp

上記のfake-ca-file、fake-cert-file、fake-key-fileは、証明書ファイルの実際のパスのプレースホルダーです。環境内にある証明書ファイルの実際のパスに変更してください。

証明書ファイルのパスの代わりにbase64にエンコードされたデータを使用したい場合は、キーに-dataの接尾辞を加えてください。例えば、certificate-authority-data、client-certificate-data、client-key-dataとできます。

それぞれのコンテキストは、クラスター、ユーザー、namespaceの三つ組からなっています。例えば、dev-frontendは、developerユーザーの認証情報を使ってdevelopmentクラスターのfrontendnamespaceへのアクセスを意味しています。

現在のコンテキストを設定してください:

kubectl config --kubeconfig=config-demo use-context dev-frontend

これ以降実行されるkubectlコマンドは、dev-frontendに設定されたクラスターとnamespaceに適用されます。また、dev-frontendに設定されたユーザーの認証情報を使用します。

現在のコンテキストの設定情報のみを確認するには、--minifyフラグを使用してください。

kubectl config --kubeconfig=config-demo view --minify

出力には、dev-frontendの設定情報が表示されます:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
current-context: dev-frontend
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file

今度は、実験用のクラスター内でしばらく作業する場合を考えます。

現在のコンテキストをexp-scratchに切り替えてください:

kubectl config --kubeconfig=config-demo use-context exp-scratch

これ以降実行されるkubectlコマンドは、scratchクラスター内のデフォルトnamespaceに適用されます。また、exp-scratchに設定されたユーザーの認証情報を使用します。

新しく切り替えたexp-scratchの設定を確認してください。

kubectl config --kubeconfig=config-demo view --minify

最後に、developmentクラスター内のstoragenamespaceでしばらく作業する場合を考えます。

現在のコンテキストをdev-storageに切り替えてください:

kubectl config --kubeconfig=config-demo use-context dev-storage

新しく切り替えたdev-storageの設定を確認してください。

kubectl config --kubeconfig=config-demo view --minify

二つ目の設定ファイルを作成する

config-exerciseディレクトリ内に、以下を含むconfig-demo-2というファイルを作成してください:

apiVersion: v1
kind: Config
preferences: {}

contexts:
- context:
    cluster: development
    namespace: ramp
    user: developer
  name: dev-ramp-up

上記の設定ファイルは、dev-ramp-upというコンテキストを表します。

KUBECONFIG環境変数を設定する

KUBECONFIGという環境変数が存在するかを確認してください。もし存在する場合は、後で復元できるようにバックアップしてください。例えば:

Linux

export KUBECONFIG_SAVED=$KUBECONFIG

Windows PowerShell

$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG

KUBECONFIG環境変数は、設定ファイルのパスのリストです。リスト内のパスはLinuxとMacではコロンで区切られ、Windowsではセミコロンで区切られます。KUBECONFIG環境変数が存在する場合は、リスト内の設定ファイルの内容を確認してください。

一時的にKUBECONFIG環境変数に以下の二つのパスを追加してください。例えば:

Linux

export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2

Windows PowerShell

$Env:KUBECONFIG=("config-demo;config-demo-2")

config-exerciseディレクトリ内から、以下のコマンドを実行してください:

kubectl config view

出力には、KUBECONFIG環境変数に含まれる全てのファイルの情報がまとめて表示されます。config-demo-2ファイルに設定されたdev-ramp-upの情報と、config-demoに設定された三つのコンテキストの情報がまとめてあることに注目してください:

contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: ramp
    user: developer
  name: dev-ramp-up
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: scratch
    namespace: default
    user: experimenter
  name: exp-scratch

kubeconfigファイルに関するさらなる情報を参照するには、kubeconfigファイルを使ってクラスターへのアクセスを管理するを参照してください。

$HOME/.kubeディレクトリの内容を確認する

既にクラスターを所持していて、kubectlを使ってクラスターを操作できる場合は、$HOME/.kubeディレクトリ内にconfigというファイルが存在する可能性が高いです。

$HOME/.kubeに移動して、そこに存在するファイルを確認してください。configという設定ファイルが存在するはずです。他の設定ファイルも存在する可能性があります。全てのファイルの中身を確認してください。

$HOME/.kube/configをKUBECONFIG環境変数に追加する

もし$HOME/.kube/configファイルが存在していて、既にKUBECONFIG環境変数に追加されていない場合は、KUBECONFIG環境変数に追加してください。例えば:

Linux

export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config

Windows Powershell

$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME/.kube/config"

KUBECONFIG環境変数内のファイルからまとめられた設定情報を確認してください。config-exerciseディレクトリ内から、以下のコマンドを実行してください:

kubectl config view

クリーンアップ

KUBECONFIG環境変数を元に戻してください。例えば:

Linux:

export KUBECONFIG=$KUBECONFIG_SAVED

Windows PowerShell

$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED

次の項目

• kubeconfigファイルを使ってクラスターへのアクセスを管理する
• kubectl config

3 - クラスター内のアプリケーションにアクセスするためにポートフォワーディングを使用する

このページでは、kubectl port-forwardを使用して、Kubernetesクラスター内で実行中のMongoDBサーバーに接続する方法について説明します。 この種の接続は、データベースのデバッグに役立ちます。

始める前に

• Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:

  • iximiuz Labs
  • Killercoda
  • KodeKloud
  • Play with Kubernetes
  作業するKubernetesサーバーは次のバージョン以降のものである必要があります: v1.10.

  バージョンを確認するには次のコマンドを実行してください: kubectl version.

• MongoDB Shellをインストールする。

MongoDBのDeploymentとServiceを作成する

1. MongoDBを実行するDeploymentを作成する:

   kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
   

   正常にコマンドが実行されると、Deploymentが作成されたことを示す出力が表示されます:

   deployment.apps/mongo created
   

   Podのステータスを表示して、準備完了であることを確認します:

   kubectl get pods
   

   出力には作成されたPodが表示されます:

   NAME                     READY   STATUS    RESTARTS   AGE
   mongo-75f59d57f4-4nd6q   1/1     Running   0          2m4s
   

   Deploymentのステータスを表示します:

   kubectl get deployment
   

   出力には、Deploymentが作成されたことが表示されます:

   NAME    READY   UP-TO-DATE   AVAILABLE   AGE
   mongo   1/1     1            1           2m21s
   

   Deploymentは自動的にReplicaSetを管理します。 ReplicaSetのステータスを表示するには、次のコマンドを使用します:

   kubectl get replicaset
   

   出力には、ReplicaSetが作成されたことが表示されます:

   NAME               DESIRED   CURRENT   READY   AGE
   mongo-75f59d57f4   1         1         1       3m12s
   

2. ネットワーク上にMongoDBを公開するためのServiceを作成します:

   kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
   

   正常にコマンドが実行されると、Serviceが作成されたことを示す出力が表示されます:

   service/mongo created
   

   Serviceが作成されたことを確認します:

   kubectl get service mongo
   

   出力には、Serviceが作成されたことが表示されます:

   NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
   mongo   ClusterIP   10.96.41.183   <none>        27017/TCP   11s
   

3. MongoDBサーバーがPod内で実行中であり、27017番ポートでリッスンしていることを確認します:

   # mongo-75f59d57f4-4nd6qをPod名に置き換えてください
   kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
   

   出力には、そのPod内のMongoDBのポートが表示されます:

    27017
   

   27017は、MongoDBの公式なTCPポートです。

ローカルポートをPodのポートにフォワードする

1. kubectl port-forwardでは、Pod名などのリソース名を指定して、ポートフォワードの対象となるPodを選択できます。

   # mongo-75f59d57f4-4nd6qを実際のPod名に置き換えてください
   kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
   

   これは、次のコマンドと同じ意味になります。

   kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017
   

   または、

   kubectl port-forward deployment/mongo 28015:27017
   

   または、

   kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017
   

   または、

   kubectl port-forward service/mongo 28015:27017
   

   上記のいずれのコマンドも有効です。出力は次のようになります:

   Forwarding from 127.0.0.1:28015 -> 27017
   Forwarding from [::1]:28015 -> 27017
   

   備考:

   kubectl port-forwardは終了せずに待機状態のままとなります。演習を続けるには、別のターミナルを開く必要があります。

2. MongoDBのコマンドラインインターフェースを起動します:

   mongosh --port 28015
   

3. MongoDBのコマンドラインプロンプトで、pingコマンドを入力します:

   db.runCommand( { ping: 1 } )
   

   pingリクエストが成功すると、次のような結果が返されます:

   { ok: 1 }
   

オプションで kubectl にローカルポートを自動割り当てさせる

特定のローカルポートを指定する必要がない場合は、kubectlにローカルポートの割り当てを任せることができます。 これにより、ローカルポートの競合を管理する必要がなくなり、構文もやや簡潔になります:

kubectl port-forward deployment/mongo :27017

kubectlツールは、使用されていないローカルポート番号を見つけて割り当てます(他のアプリケーションで使用されている可能性があるため、低いポート番号は避けられます)。 出力は次のようになります:

Forwarding from 127.0.0.1:63753 -> 27017
Forwarding from [::1]:63753 -> 27017

解説

ローカルの28015番ポートへの接続は、MongoDBサーバーを実行しているPodの27017番ポートにフォワードされます。 この接続が確立されていれば、ローカルのワークステーションから、Pod内で実行中のデータベースのデバッグを行うことができます。

次の項目

kubectl port-forwardについて詳しくは、こちらを参照してください。

4 - Serviceを利用したクラスター内のアプリケーションへのアクセス

ここでは、クラスター内で稼働しているアプリケーションに外部からアクセスするために、KubernetesのServiceオブジェクトを作成する方法を紹介します。 例として、2つのインスタンスから成るアプリケーションへのロードバランシングを扱います。

始める前に

Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

バージョンを確認するには次のコマンドを実行してください: kubectl version.

目標

• 2つのHello Worldアプリケーションを稼働させる。
• Nodeのポートを公開するServiceオブジェクトを作成する。
• 稼働しているアプリケーションにアクセスするためにServiceオブジェクトを使用する。

2つのPodから成るアプリケーションのServiceを作成

アプリケーションDeploymentの設定ファイルは以下の通りです:

service/access/hello-application.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world
spec:
  selector:
    matchLabels:
      run: load-balancer-example
  replicas: 2
  template:
    metadata:
      labels:
        run: load-balancer-example
    spec:
      containers:
        - name: hello-world
          image: gcr.io/google-samples/node-hello:1.0
          ports:
            - containerPort: 8080
              protocol: TCP

1. クラスターでHello Worldアプリケーションを稼働させます: 上記のファイルを使用し、アプリケーションのDeploymentを作成します:

   kubectl apply -f https://k8s.io/examples/service/access/hello-application.yaml
   

   このコマンドはDeploymentオブジェクトとそれに紐付くReplicaSetオブジェクトを作成します。ReplicaSetは、Hello Worldアプリケーションが稼働している2つのPodから構成されます。

2. Deploymentの情報を表示します:

   kubectl get deployments hello-world
   kubectl describe deployments hello-world
   

3. ReplicaSetオブジェクトの情報を表示します:

   kubectl get replicasets
   kubectl describe replicasets
   

4. Deploymentを公開するServiceオブジェクトを作成します:

   kubectl expose deployment hello-world --type=NodePort --name=example-service
   

5. Serviceに関する情報を表示します:

   kubectl describe services example-service
   

   出力例は以下の通りです:

   Name:                   example-service
   Namespace:              default
   Labels:                 run=load-balancer-example
   Annotations:            <none>
   Selector:               run=load-balancer-example
   Type:                   NodePort
   IP:                     10.32.0.16
   Port:                   <unset> 8080/TCP
   TargetPort:             8080/TCP
   NodePort:               <unset> 31496/TCP
   Endpoints:              10.200.1.4:8080,10.200.2.5:8080
   Session Affinity:       None
   Events:                 <none>
   

   NodePortの値を記録しておきます。上記の例では、31496です。

6. Hello Worldアプリーションが稼働しているPodを表示します:

   kubectl get pods --selector="run=load-balancer-example" --output=wide
   

   出力例は以下の通りです:

   NAME                           READY   STATUS    ...  IP           NODE
   hello-world-2895499144-bsbk5   1/1     Running   ...  10.200.1.4   worker1
   hello-world-2895499144-m1pwt   1/1     Running   ...  10.200.2.5   worker2
   

7. Hello World podが稼働するNodeのうち、いずれか1つのパブリックIPアドレスを確認します。 確認方法は、使用している環境により異なります。 例として、Minikubeの場合はkubectl cluster-info、Google Compute Engineの場合はgcloud compute instances listによって確認できます。

8. 選択したノード上で、NodePortの値でのTCP通信を許可するファイヤーウォールを作成します。 NodePortの値が31568の場合、31568番のポートを利用したTCP通信を許可するファイヤーウォールを作成します。 クラウドプロバイダーによって設定方法が異なります。

9. Hello World applicationにアクセスするために、Nodeのアドレスとポート番号を使用します:

   curl http://<public-node-ip>:<node-port>
   

   ここで <public-node-ip> はNodeのパブリックIPアドレス、 <node-port> はNodePort Serviceのポート番号の値を表しています。 リクエストが成功すると、下記のメッセージが表示されます:

   Hello Kubernetes!
   

service configuration fileの利用

kubectl exposeコマンドの代わりに、 service configuration file を使用してServiceを作成することもできます。

クリーンアップ

Serviceを削除するには、以下のコマンドを実行します:

kubectl delete services example-service

Hello Worldアプリケーションが稼働しているDeployment、ReplicaSet、Podを削除するには、以下のコマンドを実行します:

kubectl delete deployment hello-world

次の項目

詳細は serviceを利用してアプリケーションと接続する を確認してください。

5 - Serviceを使用してフロントエンドをバックエンドに接続する

このタスクでは、フロントエンドとバックエンドのマイクロサービスを作成する方法を示します。 バックエンドのマイクロサービスは挨拶です。 フロントエンドとバックエンドは、Kubernetes Serviceオブジェクトを使用して接続されます。

目標

• Deploymentオブジェクトを使用してマイクロサービスを作成および実行します。
• フロントエンドを経由してトラフィックをバックエンドにルーティングします。
• Serviceオブジェクトを使用して、フロントエンドアプリケーションをバックエンドアプリケーションに接続します。

始める前に

Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

バージョンを確認するには次のコマンドを実行してください: kubectl version.

このタスクではServiceで外部ロードバランサーを使用しますが、外部ロードバランサーの使用がサポートされている環境である必要があります。 ご使用の環境がこれをサポートしていない場合は、代わりにタイプNodePortのServiceを使用できます。

Deploymentを使用したバックエンドの作成

バックエンドは、単純な挨拶マイクロサービスです。 バックエンドのDeploymentの構成ファイルは次のとおりです:

service/access/hello.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  selector:
    matchLabels:
      app: hello
      tier: backend
      track: stable
  replicas: 7
  template:
    metadata:
      labels:
        app: hello
        tier: backend
        track: stable
    spec:
      containers:
        - name: hello
          image: "gcr.io/google-samples/hello-go-gke:1.0"
          ports:
            - name: http
              containerPort: 80

バックエンドのDeploymentを作成します:

kubectl apply -f https://k8s.io/examples/service/access/hello.yaml

バックエンドのDeploymentに関する情報を表示します:

kubectl describe deployment hello

出力はこのようになります:

Name:                           hello
Namespace:                      default
CreationTimestamp:              Mon, 24 Oct 2016 14:21:02 -0700
Labels:                         app=hello
                                tier=backend
                                track=stable
Annotations:                    deployment.kubernetes.io/revision=1
Selector:                       app=hello,tier=backend,track=stable
Replicas:                       7 desired | 7 updated | 7 total | 7 available | 0 unavailable
StrategyType:                   RollingUpdate
MinReadySeconds:                0
RollingUpdateStrategy:          1 max unavailable, 1 max surge
Pod Template:
  Labels:       app=hello
                tier=backend
                track=stable
  Containers:
   hello:
    Image:              "gcr.io/google-samples/hello-go-gke:1.0"
    Port:               80/TCP
    Environment:        <none>
    Mounts:             <none>
  Volumes:              <none>
Conditions:
  Type          Status  Reason
  ----          ------  ------
  Available     True    MinimumReplicasAvailable
  Progressing   True    NewReplicaSetAvailable
OldReplicaSets:                 <none>
NewReplicaSet:                  hello-3621623197 (7/7 replicas created)
Events:
...

バックエンドServiceオブジェクトの作成

フロントエンドをバックエンドに接続する鍵は、バックエンドServiceです。 Serviceは、バックエンドマイクロサービスに常に到達できるように、永続的なIPアドレスとDNS名のエントリを作成します。 Serviceはセレクターを使用して、トラフィックをルーティングするPodを見つけます。

まず、Service構成ファイルを調べます:

service/access/hello-service.yaml

kind: Service
apiVersion: v1
metadata:
  name: hello
spec:
  selector:
    app: hello
    tier: backend
  ports:
  - protocol: TCP
    port: 80
    targetPort: http

設定ファイルで、Serviceがapp：helloおよびtier：backendというラベルを持つPodにトラフィックをルーティングしていることがわかります。

hello Serviceを作成します:

kubectl apply -f https://k8s.io/examples/service/access/hello-service.yaml

この時点で、バックエンドのDeploymentが実行され、そちらにトラフィックをルーティングできるServiceがあります。

フロントエンドの作成

バックエンドができたので、バックエンドに接続するフロントエンドを作成できます。 フロントエンドは、バックエンドServiceに指定されたDNS名を使用して、バックエンドワーカーPodに接続します。 DNS名はhelloです。これは、前のサービス設定ファイルのnameフィールドの値です。

フロントエンドDeploymentのPodは、helloバックエンドServiceを見つけるように構成されたnginxイメージを実行します。 これはnginx設定ファイルです:

service/access/frontend.conf

upstream hello {
    server hello;
}
server {
listen 80;
location / {
    proxy_pass http://hello;
}

}

バックエンドと同様に、フロントエンドにはDeploymentとServiceがあります。 Serviceの設定にはtype：LoadBalancerがあります。これは、Serviceがクラウドプロバイダーのデフォルトのロードバランサーを使用することを意味します。

service/access/frontend.yaml

apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  selector:
    app: hello
    tier: frontend
  ports:
  - protocol: "TCP"
    port: 80
    targetPort: 80
  type: LoadBalancer
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  selector:
    matchLabels:
      app: hello
      tier: frontend
      track: stable
  replicas: 1
  template:
    metadata:
      labels:
        app: hello
        tier: frontend
        track: stable
    spec:
      containers:
      - name: nginx
        image: "gcr.io/google-samples/hello-frontend:1.0"
        lifecycle:
          preStop:
            exec:
              command: ["/usr/sbin/nginx","-s","quit"]

フロントエンドのDeploymentとServiceを作成します:

kubectl apply -f https://k8s.io/examples/service/access/frontend.yaml

出力結果から両方のリソースが作成されたことを確認します:

deployment.apps/frontend created
service/frontend created

フロントエンドServiceと対話

LoadBalancerタイプのServiceを作成したら、このコマンドを使用して外部IPを見つけることができます:

kubectl get service frontend --watch

これによりfrontend Serviceの設定が表示され、変更が監視されます。 最初、外部IPは<pending>としてリストされます:

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)  AGE
frontend   LoadBalancer   10.51.252.116   <pending>     80/TCP   10s

ただし、外部IPがプロビジョニングされるとすぐに、EXTERNAL-IPという見出しの下に新しいIPが含まれるように構成が更新されます:

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)  AGE
frontend   LoadBalancer   10.51.252.116   XXX.XXX.XXX.XXX    80/TCP   1m

このIPを使用して、クラスターの外部からfrontend Serviceとやり取りできるようになりました。

フロントエンドを介するトラフィック送信

フロントエンドとバックエンドが接続されました。 フロントエンドServiceの外部IPに対してcurlコマンドを使用して、エンドポイントにアクセスできます。

curl http://${EXTERNAL_IP} # これを前に見たEXTERNAL-IPに置き換えます

出力には、バックエンドによって生成されたメッセージが表示されます:

{"message":"Hello"}

クリーンアップ

Serviceを削除するには、このコマンドを入力してください：

kubectl delete services frontend hello

バックエンドとフロントエンドアプリケーションを実行しているDeploymentとReplicaSetとPodを削除するために、このコマンドを入力してください：

kubectl delete deployment frontend hello

次の項目

• Serviceの詳細
• ConfigMapの詳細

6 - 外部ロードバランサーを作成する

このページでは、外部ロードバランサーを作成する方法について説明します。

Serviceを作成する際に、クラウドロードバランサーを自動的に作成するオプションがあります。 これにより、外部からアクセス可能なIPアドレスが割り当てられ、そのIPからのトラフィックがクラスター内のノード上の正しいポートへと送信されます。 ただし、クラスターが対応する環境で実行されており、適切なクラウドロードバランサープロバイダーのパッケージが構成されている必要があります。

Serviceの代わりに、Ingressを使用することもできます。 詳細については、Ingressのドキュメントを参照してください。

始める前に

Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

クラスターは、外部ロードバランサーの構成をサポートするクラウド環境、またはそれに相当する他の環境上で実行されている必要があります。

Serviceを作成する

マニフェストからServiceを作成する

外部ロードバランサーを作成するには、Serviceのマニフェストに次の行を追加します:

    type: LoadBalancer

マニフェストは次のようになります:

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  selector:
    app: example
  ports:
    - port: 8765
      targetPort: 9376
  type: LoadBalancer

kubectlを使用してServiceを作成する

代わりに、kubectl exposeコマンドとその--type=LoadBalancerフラグを使用してServiceを作成することも可能です:

kubectl expose deployment example --port=8765 --target-port=9376 \
        --name=example-service --type=LoadBalancer

このコマンドは、参照されているリソース(上記の例ではexampleという名前のDeployment)と同じセレクターを使用して、新しいServiceを作成します。

オプションのフラグを含む詳細については、kubectl exposeのリファレンスを参照してください。

IPアドレスの確認

kubectlを使用してサービスの情報を取得することで、そのサービスに割り当てられたIPアドレスを確認できます:

kubectl describe services example-service

このコマンドの出力は次のようになります:

Name:                     example-service
Namespace:                default
Labels:                   app=example
Annotations:              <none>
Selector:                 app=example
Type:                     LoadBalancer
IP Families:              <none>
IP:                       10.3.22.96
IPs:                      10.3.22.96
LoadBalancer Ingress:     192.0.2.89
Port:                     <unset>  8765/TCP
TargetPort:               9376/TCP
NodePort:                 <unset>  30593/TCP
Endpoints:                172.17.0.3:9376
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

ロードバランサーのIPアドレスは、LoadBalancer Ingressの横に表示されます。

minikube service example-service --url

クライアントの送信元IPアドレスを保持する

デフォルトでは、ターゲットコンテナから見える送信元IPは、クライアントの元の送信元IPアドレスではありません。 クライアントIPの保持を有効にするには、Serviceの.spec内で次のフィールドを設定する必要があります:

• .spec.externalTrafficPolicy - このServiceが外部トラフィックをノードローカルのエンドポイントにルーティングするか、クラスター全体のエンドポイントにルーティングするかを指定します。指定可能な値はCluster(デフォルト)とLocalの2つです。Clusterを指定するとクライアントの送信元IPは隠蔽され、他のノードへの2回目のホップが発生する可能性がありますが、全体的な負荷分散は良好になります。Localを指定するとクライアントの送信元IPが保持され、LoadBalancer型およびNodePort型Serviceにおいて2回目のホップを回避できますが、トラフィックの分散が偏るリスクがあります。
• .spec.healthCheckNodePort - サービスのヘルスチェック用ノードポート(数値のポート番号)を指定します。healthCheckNodePortを指定しない場合、サービスコントローラーがクラスターのNodePortレンジから自動的にポートを割り当てます。 このポートレンジは、APIサーバーのコマンドラインオプション--service-node-port-rangeで設定できます。ServiceのtypeがLoadBalancerで、externalTrafficPolicyがLocalに設定されている場合に限り、指定したhealthCheckNodePortの値が使用されます。

ServiceのマニフェストでexternalTrafficPolicyをLocalに設定することで、この機能が有効になります。 たとえば、次のように指定します:

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  selector:
    app: example
  ports:
    - port: 8765
      targetPort: 9376
  externalTrafficPolicy: Local
  type: LoadBalancer

送信元IPアドレスを保持する際の注意点と制限事項

一部のクラウドプロバイダーが提供するロードバランサーサービスでは、各ターゲットに対して異なる重みを設定することができません。

各ターゲットがノードへのトラフィック送信において等しく重み付けされているため、外部トラフィックは異なるPod間で均等に負荷分散されません。外部ロードバランサーは、ターゲットとして使用される各ノード上のPod数を認識していません。

NumServicePods << NumNodesまたはNumServicePods >> NumNodesの場合、重み付けがなくても、かなり均等に近い分散が見られます。

Pod間の内部トラフィックは、すべてのPodに対して等しい確率で、ClusterIPサービスと同様の動作をするはずです。

ロードバランサーのガベージコレクション

通常、LoadBalancer型Serviceが削除されると、それに関連付けられたクラウドプロバイダー上のロードバランサーリソースも速やかにクリーンアップされるはずです。 しかし、Serviceの削除後に関連するクラウドリソースが孤立状態になるさまざまなコーナーケースが知られています。 これを防ぐために、「Service LoadBalancerのFinalizer保護」が導入されました。 Finalizerを使用することで、対応するロードバランサーリソースが削除されるまでは、Serviceリソース自体も削除されなくなります。

具体的には、typeがLoadBalancerであるServiceには、service.kubernetes.io/load-balancer-cleanupという名前のFinalizerがサービスコントローラーによって付与されます。 このFinalizerは、ロードバランサーリソースがクリーンアップされるまで削除されません。 これにより、たとえばサービスコントローラーがクラッシュするようなコーナーケースにおいても、ロードバランサーリソースが取り残されるのを防ぐことができます。

外部ロードバランサープロバイダー

この機能のデータパスは、Kubernetesクラスター外部のロードバランサーによって提供されることに注意が必要です。

ServiceのtypeがLoadBalancerに設定されている場合、Kubernetesはクラスター内のPodに対してはtypeがClusterIPに相当する機能を提供し、さらに(Kubernetesの外部にある)ロードバランサーに、該当するPodをホストしているノードの情報を登録することで、この機能を拡張します。 Kubernetesのコントロールプレーンは、外部ロードバランサーの作成、必要に応じたヘルスチェックやパケットフィルタリングルールの設定を自動で行います。 クラウドプロバイダーによってロードバランサーのIPアドレスが割り当てられると、コントロールプレーンはその外部IPアドレスを取得し、Serviceオブジェクトに反映します。

次の項目

• アプリケーションをServiceに接続するチュートリアルを参照してください
• Serviceについて読む
• Ingressについて読む

7 - クラスターで実行されているすべてのコンテナイメージを一覧表示する

このページでは、kubectlを使用して、クラスターで実行されているPodのすべてのコンテナイメージを一覧表示する方法を説明します。

始める前に

Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

バージョンを確認するには次のコマンドを実行してください: kubectl version.

この演習では、kubectlを使用してクラスターで実行されているすべてのPodを取得し、出力をフォーマットしてそれぞれのコンテナの一覧を取得します。

すべての名前空間のコンテナイメージを一覧表示する

• kubectl get pods --all-namespacesを使用して、すべての名前空間のPodを取得します
• -o jsonpath={.. image}を使用して、コンテナイメージ名のリストのみが含まれるように出力をフォーマットします。これは、返されたjsonのimageフィールドを再帰的に解析します。
  • jsonpathの使い方については、jsonpathリファレンスを参照してください。
• tr、sort、uniqなどの標準ツールを使用して出力をフォーマットします。
  • trを使用してスペースを改行に置換します。
  • sortを使用して結果を並べ替えます。
  • uniqを使用してイメージ数を集計します。

kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -c

上記のコマンドは、返されるすべてのアイテムについて、imageという名前のすべてのフィールドを再帰的に返します。

別の方法として、Pod内のimageフィールドへの絶対パスを使用することができます。これにより、フィールド名が繰り返されている場合でも正しいフィールドが取得されます。多くのフィールドは与えられたアイテム内でnameと呼ばれます:

kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}"

jsonpathは次のように解釈されます:

• .items[*]: 各戻り値
• .spec: 仕様の取得
• .containers[*]: 各コンテナ
• .image: イメージの取得

Podごとにコンテナイメージを一覧表示する

rangeを使用して要素を個別に繰り返し処理することにより、フォーマットをさらに制御できます。

kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
sort

Podのラベルを使用してコンテナイメージ一覧をフィルタリングする

特定のラベルに一致するPodのみを対象とするには、-lフラグを使用します。以下は、app=nginxに一致するラベルを持つPodのみに一致します。

kubectl get pods --all-namespaces -o jsonpath="{..image}" -l app=nginx

Podの名前空間でコンテナイメージ一覧をフィルタリングする

特定の名前空間のPodのみを対象とするには、namespaceフラグを使用します。以下はkube-system名前空間のPodのみに一致します。

kubectl get pods --namespace kube-system -o jsonpath="{..image}"

jsonpathの代わりにgo-templateを使用してコンテナイメージを一覧表示する

jsonpathの代わりに、kubectlはgo-templatesを使用した出力のフォーマットをサポートしています:

kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}"

次の項目

参照

• jsonpath参照ガイド
• Go template参照ガイド

8 - Minikube上でNGINX Ingressコントローラーを使用してIngressをセットアップする

Ingressとは、クラスター内のServiceに外部からのアクセスを許可するルールを定義するAPIオブジェクトです。IngressコントローラーはIngress内に設定されたルールを満たすように動作します。

このページでは、簡単なIngressをセットアップして、HTTPのURIに応じてwebまたはweb2というServiceにリクエストをルーティングする方法を説明します。

始める前に

Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

バージョンを確認するには次のコマンドを実行してください: kubectl version.

Minikubeクラスターを作成する

1. Launch Terminalをクリックします。

2. (オプション) Minikubeをローカル環境にインストールした場合は、次のコマンドを実行します。

   minikube start
   

Ingressコントローラーを有効化する

1. NGINX Ingressコントローラーを有効にするために、次のコマンドを実行します。

   minikube addons enable ingress
   

2. NGINX Ingressコントローラーが起動したことを確認します。

   kubectl get pods -n kube-system
   

   備考:

   このコマンドの実行には数分かかる場合があります。
   

   出力は次のようになります。

   NAME                                        READY     STATUS    RESTARTS   AGE
   default-http-backend-59868b7dd6-xb8tq       1/1       Running   0          1m
   kube-addon-manager-minikube                 1/1       Running   0          3m
   kube-dns-6dcb57bcc8-n4xd4                   3/3       Running   0          2m
   kubernetes-dashboard-5498ccf677-b8p5h       1/1       Running   0          2m
   nginx-ingress-controller-5984b97644-rnkrg   1/1       Running   0          1m
   storage-provisioner                         1/1       Running   0          2m
   

Hello Worldアプリをデプロイする

1. 次のコマンドを実行して、Deploymentを作成します。

   kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
   

   出力は次のようになります。

   deployment.apps/web created
   

2. Deploymentを公開します。

   kubectl expose deployment web --type=NodePort --port=8080
   

   出力は次のようになります。

   service/web exposed
   

3. Serviceが作成され、NodePort上で利用できるようになったことを確認します。

   kubectl get service web
   

   出力は次のようになります。

   NAME      TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
   web       NodePort   10.104.133.249   <none>        8080:31637/TCP   12m
   

4. NodePort経由でServiceを訪問します。

   minikube service web --url
   

   出力は次のようになります。

   http://172.17.0.15:31637
   

   出力は次のようになります。

   Hello, world!
   Version: 1.0.0
   Hostname: web-55b8c6998d-8k564
   

   これで、MinikubeのIPアドレスとNodePort経由で、サンプルアプリにアクセスできるようになりました。次のステップでは、Ingressリソースを使用してアプリにアクセスできるように設定します。

Ingressリソースを作成する

以下に示すファイルは、hello-world.info経由で送られたトラフィックをServiceに送信するIngressリソースです。

1. 以下の内容でexample-ingress.yamlを作成します。

   service/networking/example-ingress.yaml

   apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-ingress
    spec:
      ingressClassName: nginx
      rules:
        - host: hello-world.info
          http:
            paths:
              - path: /
                pathType: Prefix
                backend:
                  service:
                    name: web
                    port:
                      number: 8080

2. 次のコマンドを実行して、Ingressリソースを作成します。

   kubectl apply -f https://kubernetes.io/examples/service/networking/example-ingress.yaml
   

   出力は次のようになります。

   ingress.networking.k8s.io/example-ingress created
   

3. 次のコマンドで、IPアドレスが設定されていることを確認します。

   kubectl get ingress
   

   備考:

   このコマンドの実行には数分かかる場合があります。
   

   NAME              CLASS    HOSTS              ADDRESS        PORTS   AGE
   example-ingress   <none>   hello-world.info   172.17.0.15    80      38s
   

4. 次の行を/etc/hostsファイルの最後に書きます。

   備考:

   Minikubeをローカル環境で実行している場合、`minikube ip`コマンドを使用すると外部のIPが取得できます。Ingressのリスト内に表示されるIPアドレスは、内部のIPになるはずです。
   

   172.17.0.15 hello-world.info
   

   この設定により、リクエストがhello-world.infoからMinikubeに送信されるようになります。

5. Ingressコントローラーがトラフィックを制御していることを確認します。

   curl hello-world.info
   

   出力は次のようになります。

   Hello, world!
   Version: 1.0.0
   Hostname: web-55b8c6998d-8k564
   

   備考:

   Minikubeをローカル環境で実行している場合、ブラウザからhello-world.infoにアクセスできます。
   

2番目のDeploymentを作成する

1. 次のコマンドを実行して、v2のDeploymentを作成します。

   kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
   

   出力は次のようになります。

   deployment.apps/web2 created
   

2. Deploymentを公開します。

   kubectl expose deployment web2 --port=8080 --type=NodePort
   

   出力は次のようになります。

   service/web2 exposed
   

Ingressを編集する

1. 既存のexample-ingress.yamlを編集して、以下の行を追加します。

         - path: /v2
           pathType: Prefix
           backend:
             service:
               name: web2
               port:
                 number: 8080
   

2. 次のコマンドで変更を適用します。

   kubectl apply -f example-ingress.yaml
   

   出力は次のようになります。

   ingress.networking/example-ingress configured
   

Ingressを試す

1. Hello Worldアプリの1番目のバージョンにアクセスします。

   curl hello-world.info
   

   出力は次のようになります。

   Hello, world!
   Version: 1.0.0
   Hostname: web-55b8c6998d-8k564
   

2. Hello Worldアプリの2番目のバージョンにアクセスします。

   curl hello-world.info/v2
   

   出力は次のようになります。

   Hello, world!
   Version: 2.0.0
   Hostname: web2-75cd47646f-t8cjk
   

   備考:

   Minikubeをローカル環境で実行している場合、ブラウザからhello-world.infoおよびhello-world.info/v2にアクセスできます。
   

次の項目

• Ingressについてさらに学ぶ。
• Ingressコントローラーについてさらに学ぶ。
• Serviceについてさらに学ぶ。

9 - 共有ボリュームを使用して同じPod内のコンテナ間で通信する

このページでは、ボリュームを使用して、同じPodで実行されている2つのコンテナ間で通信する方法を示します。 コンテナ間でプロセス名前空間を共有することにより、プロセスが通信できるようにする方法も参照してください。

始める前に

Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

バージョンを確認するには次のコマンドを実行してください: kubectl version.

2つのコンテナを実行するPodの作成

この演習では、2つのコンテナを実行するPodを作成します。 2つのコンテナは、通信に使用できるボリュームを共有します。 これがPodの設定ファイルです:

pods/two-container-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: two-containers
spec:

  restartPolicy: Never

  volumes:
  - name: shared-data
    emptyDir: {}

  containers:

  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html

  - name: debian-container
    image: debian
    volumeMounts:
    - name: shared-data
      mountPath: /pod-data
    command: ["/bin/sh"]
    args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]

設定ファイルで、Podにshared-dataという名前のボリュームがあることがわかります。

設定ファイルにリストされている最初のコンテナは、nginxサーバーを実行します。 共有ボリュームのマウントパスは/usr/share/nginx/htmlです。 2番目のコンテナはdebianイメージをベースとしており、/pod-dataのマウントパスを持っています。 2番目のコンテナは次のコマンドを実行してから終了します。

echo Hello from the debian container > /pod-data/index.html

2番目のコンテナがnginxサーバーのルートディレクトリにindex.htmlファイルを書き込むことに注意してください。

Podと2つのコンテナを作成します:

kubectl apply -f https://k8s.io/examples/pods/two-container-pod.yaml

Podとコンテナに関する情報を表示します:

kubectl get pod two-containers --output=yaml

こちらは出力の一部です:

apiVersion: v1
kind: Pod
metadata:
  ...
  name: two-containers
  namespace: default
  ...
spec:
  ...
  containerStatuses:

  - containerID: docker://c1d8abd1 ...
    image: debian
    ...
    lastState:
      terminated:
        ...
    name: debian-container
    ...

  - containerID: docker://96c1ff2c5bb ...
    image: nginx
    ...
    name: nginx-container
    ...
    state:
      running:
    ...

debianコンテナが終了し、nginxコンテナがまだ実行されていることがわかります。

nginxコンテナへのシェルを取得します:

kubectl exec -it two-containers -c nginx-container -- /bin/bash

シェルで、nginxが実行されていることを確認します:

root@two-containers:/# apt-get update
root@two-containers:/# apt-get install curl procps
root@two-containers:/# ps aux

出力はこのようになります:

USER       PID  ...  STAT START   TIME COMMAND
root         1  ...  Ss   21:12   0:00 nginx: master process nginx -g daemon off;

debianコンテナがnginxルートディレクトリにindex.htmlファイルを作成したことを思い出してください。 curlを使用して、GETリクエストをnginxサーバーに送信します:

root@two-containers:/# curl localhost

出力は、nginxがdebianコンテナによって書かれたWebページを提供することを示しています:

Hello from the debian container

議論

Podが複数のコンテナを持つことができる主な理由は、プライマリアプリケーションを支援するヘルパーアプリケーションをサポートするためです。 ヘルパーアプリケーションの典型的な例は、データプラー、データプッシャー、およびプロキシです。 多くの場合、ヘルパーアプリケーションとプライマリアプリケーションは互いに通信する必要があります。 通常、これは、この演習に示すように共有ファイルシステムを介して、またはループバックネットワークインターフェースであるlocalhostを介して行われます。 このパターンの例は、新しい更新のためにGitリポジトリをポーリングするヘルパープログラムを伴うWebサーバーです。

この演習のボリュームは、コンテナがポッドの寿命中に通信する方法を提供します。 Podを削除して再作成すると、共有ボリュームに保存されているデータはすべて失われます。

次の項目

• 複合コンテナのパターンの詳細

• モジュラーアーキテクチャ用の複合コンテナについて学ぶ

• ストレージにボリュームを使用するPodの構成を参照

• Pod内のコンテナ間でプロセス名前空間を共有するPodの構成を参照

• Volumeを参照

• Podを参照

10 - クラスターのDNSを設定する

Kubernetesは、DNSクラスターアドオンを提供しており、サポートされているほとんどの環境ではデフォルトで有効になっています。 Kubernetesバージョン1.11以降では、CoreDNSが推奨されており、kubeadmでデフォルトでインストールされます。

KubernetesクラスターでCoreDNSを構成する方法の詳細については、DNSサービスのカスタマイズを参照してください。 kube-dnsを使用してKubernetes DNSを利用する方法の例については、Kubernetes DNSサンプルプラグインを参照してください。