Kubernetes-概要

Cloud Native Computing Foundation（CNCF）がホストするオープンソースコンテナー管理ツールのKubernetes。これは、以前は別のシステムで処理されていた長時間実行プロセスとバッチジョブの両方を管理するためにGoogleで開発されたBorgの拡張バージョンとしても知られています。

Kubernetesには、デプロイメントの自動化、アプリケーションのスケーリング、およびクラスター全体でのアプリケーションコンテナーの操作の機能が備わっています。コンテナ中心のインフラストラクチャを作成できます。

Kubernetesの機能

Kubernetesの重要な機能の一部を次に示します。

開発、統合、展開を継続
コンテナ化されたインフラストラクチャ
アプリケーション中心の管理
自動拡張可能なインフラストラクチャ
開発テストと本番環境での環境の一貫性
各コンポーネントが個別のユニットとして機能できる疎結合インフラストラクチャ
リソース使用率の高密度 *作成される予定の予測可能なインフラストラクチャ

Kubernetesの主要コンポーネントの1つは、物理および仮想マシンインフラストラクチャのクラスターでアプリケーションを実行できることです。また、クラウド上でアプリケーションを実行する機能も備えています。* ホスト中心のインフラストラクチャからコンテナ中心のインフラストラクチャへの移行に役立ちます。*

Kubernetes-アーキテクチャ

この章では、Kubernetesの基本アーキテクチャについて説明します。

Kubernetes-クラスターアーキテクチャ

次の図に示すように、Kubernetesはクライアントサーバーアーキテクチャに従います。ここで、マスターは1台のマシンにインストールされ、ノードは別のLinuxマシンにインストールされています。

クラスターアーキテクチャ

マスターとノードの主要なコンポーネントは、次のセクションで定義されます。

Kubernetes-マスターマシンコンポーネント

Kubernetes Master Machineのコンポーネントは次のとおりです。

etcd

クラスター内の各ノードで使用できる構成情報を保存します。これは、複数のノードに分散できる高可用性キーバリューストアです。機密情報が含まれている可能性があるため、Kubernetes APIサーバーからのみアクセスできます。これは、すべてにアクセス可能な分散キー値ストアです。

APIサーバー

Kubernetesは、APIを使用してクラスターですべての操作を提供するAPIサーバーです。 APIサーバーはインターフェースを実装します。つまり、さまざまなツールやライブラリが簡単に通信できます。 Kubeconfig は、通信に使用できるサーバー側ツールと一緒のパッケージです。 Kubernetes APIを公開します。

コントローラーマネージャー

このコンポーネントは、クラスターの状態を調整してタスクを実行するほとんどのコレクターを担当します。一般に、それは非終了ループで実行され、APIサーバーへの情報の収集と送信を担当するデーモンと見なすことができます。クラスターの共有状態を取得し、サーバーの現在のステータスを目的の状態にするために変更を行います。キーコントローラーは、レプリケーションコントローラー、エンドポイントコントローラー、名前空間コントローラー、およびサービスアカウントコントローラーです。コントローラーマネージャーは、さまざまな種類のコントローラーを実行して、ノード、エンドポイントなどを処理します。

スケジューラー

これはKubernetesマスターの重要なコンポーネントの1つです。ワークロードの分散を担当するマスターのサービスです。クラスターノードの作業負荷の使用率を追跡し、リソースが利用可能なワークロードを配置し、ワークロードを受け入れます。言い換えれば、これはポッドを利用可能なノードに割り当てる責任があるメカニズムです。スケジューラーは、ワークロードの使用率と新しいノードへのポッドの割り当てを担当します。

Kubernetes-ノードコンポーネント

以下は、Kubernetesマスターと通信するために必要なノードサーバーの主要コンポーネントです。

港湾労働者

各ノードの最初の要件はDockerです。これは、カプセル化されたアプリケーションコンテナーを比較的孤立しているが軽量なオペレーティング環境で実行するのに役立ちます。

キューブレットサービス

これは、コントロールプレーンサービスとの間で情報を中継する各ノードの小さなサービスです。 etcd ストアと対話して、構成の詳細とライトの値を読み取ります。これは、コマンドを受信して作業するためにマスターコンポーネントと通信します。その後、 kubelet プロセスは、作業状態とノードサーバーを維持する責任を負います。ネットワークルール、ポート転送などを管理します。

Kubernetesプロキシサービス

これは各ノードで実行されるプロキシサービスであり、外部ホストでサービスを利用できるようにします。要求を正しいコンテナに転送するのに役立ち、プリミティブな負荷分散を実行できます。これにより、ネットワーク環境が予測可能でアクセスしやすくなり、同時に隔離されます。ノード上のポッド、ボリューム、シークレットの管理、新しいコンテナの健康診断の作成など。

Kubernetes-マスターおよびノード構造

次の図は、Kubernetesマスターとノードの構造を示しています。

マスターおよびノード構造

Kubernetes-セットアップ

Kubernetesをセットアップする前に、仮想データセンター（vDC）をセットアップすることが重要です。これは、ネットワークを介して互いに通信できる一連のマシンと見なすことができます。実践的なアプローチでは、物理インフラストラクチャまたはクラウドインフラストラクチャがセットアップされていない場合、 PROFITBRICKS でvDCをセットアップできます。

クラウドでのIaaSのセットアップが完了したら、*マスター*と*ノード*を構成する必要があります。

注-Ubuntuマシンのセットアップが表示されます。同じことが他のLinuxマシンでも設定できます。

前提条件

Dockerのインストール*-KubernetesのすべてのインスタンスでDockerが必要です。 Dockerをインストールする手順は次のとおりです。

ステップ1 *-rootユーザーアカウントでマシンにログオンします。

ステップ2 *-パッケージ情報を更新します。 aptパッケージが機能していることを確認してください。

ステップ3 *-次のコマンドを実行します。

$ sudo apt-get update
$ sudo apt-get install apt-transport-https ca-certificates

ステップ4 *-新しいGPGキーを追加します。

$ sudo apt-key adv \
   --keyserver hkp://ha.pool.sks-keyservers.net:80 \
   --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
$ echo "deb https://apt.dockerproject.org/repo ubuntu-trusty main" | sudo tee
/etc/apt/sources.list.d/docker.list

ステップ5 *-APIパッケージイメージを更新します。

$ sudo apt-get update

上記のすべてのタスクが完了したら、Dockerエンジンの実際のインストールから開始できます。ただし、これの前に、使用しているカーネルのバージョンが正しいことを確認する必要があります。

Docker Engineをインストールする

次のコマンドを実行して、Dockerエンジンをインストールします。

ステップ1 *-マシンにログオンします。

ステップ2 *-パッケージインデックスを更新します。

$ sudo apt-get update

ステップ3 *-次のコマンドを使用してDocker Engineをインストールします。

$ sudo apt-get install docker-engine

ステップ4 *-Dockerデーモンを起動します。

$ sudo apt-get install docker-engine

ステップ5 *-Dockerがインストールされている場合は、次のコマンドを使用します。

$ sudo docker run hello-world

etcd 2.0をインストールする

これはKubernetes Master Machineにインストールする必要があります。それをインストールするには、次のコマンドを実行します。

$ curl -L https://github.com/coreos/etcd/releases/download/v2.0.0/etcd
-v2.0.0-linux-amd64.tar.gz -o etcd-v2.0.0-linux-amd64.tar.gz ->1
$ tar xzvf etcd-v2.0.0-linux-amd64.tar.gz ------>2
$ cd etcd-v2.0.0-linux-amd64 ------------>3
$ mkdir/opt/bin ------------->4
$ cp etcd*/opt/bin ----------->5

コマンドの上記のセットで-

まず、 etcd をダウンロードします。指定した名前でこれを保存します。
次に、tarパッケージを展開する必要があります。
dirを作成します。/optという名前のビン内。
抽出したファイルをターゲットの場所にコピーします。

これでKubernetesを構築する準備ができました。クラスタ上のすべてのマシンにKubernetesをインストールする必要があります。

$ git clone https://github.com/GoogleCloudPlatform/kubernetes.git
$ cd kubernetes
$ make release

上記のコマンドは、kubernetesフォルダーのルートに _output ディレクトリーを作成します。次に、選択した任意のディレクトリ/opt/binなどにディレクトリを抽出できます。

次に、Kubernetesマスターとノードのセットアップから実際に開始する必要があるネットワーキング部分が来ます。これを行うには、ノードマシンで実行できるホストファイルにエントリを作成します。

$ echo "<IP address of master machine> kube-master
< IP address of Node Machine>" >>/etc/hosts

上記のコマンドの出力は次のとおりです。

出力

次に、Kubernetes Masterの実際の構成から始めます。

最初に、すべての構成ファイルの正しい場所へのコピーを開始します。

$ cp <Current dir. location>/kube-apiserver/opt/bin/
$ cp <Current dir. location>/kube-controller-manager/opt/bin/
$ cp <Current dir. location>/kube-kube-scheduler/opt/bin/
$ cp <Current dir. location>/kubecfg/opt/bin/
$ cp <Current dir. location>/kubectl/opt/bin/
$ cp <Current dir. location>/kubernetes/opt/bin/

上記のコマンドは、すべての構成ファイルを必要な場所にコピーします。ここで、Kubernetesフォルダーを作成したのと同じディレクトリに戻ります。

$ cp kubernetes/cluster/ubuntu/init_conf/kube-apiserver.conf/etc/init/
$ cp kubernetes/cluster/ubuntu/init_conf/kube-controller-manager.conf/etc/init/
$ cp kubernetes/cluster/ubuntu/init_conf/kube-kube-scheduler.conf/etc/init/

$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-apiserver/etc/init.d/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-controller-manager/etc/init.d/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-kube-scheduler/etc/init.d/

$ cp kubernetes/cluster/ubuntu/default_scripts/kubelet/etc/default/
$ cp kubernetes/cluster/ubuntu/default_scripts/kube-proxy/etc/default/
$ cp kubernetes/cluster/ubuntu/default_scripts/kubelet/etc/default/

次のステップは、コピーされた構成ファイルを/etcの下で更新することです。 dir.

次のコマンドを使用して、マスターでetcdを構成します。

$ ETCD_OPTS = "-listen-client-urls = http://kube-master:4001"

kube-apiserverを構成する

マスターでこれを行うには、前にコピーした /etc/default/kube-apiserver ファイルを編集する必要があります。

$ KUBE_APISERVER_OPTS = "--address = 0.0.0.0 \
--port = 8080 \
--etcd_servers = <The path that is configured in ETCD_OPTS> \
--portal_net = 11.1.1.0/24 \
--allow_privileged = false \
--kubelet_port = < Port you want to configure> \
--v = 0"

kube Controller Managerを構成する

*/etc/default/kube-controller-manager* に次のコンテンツを追加する必要があります。

$ KUBE_CONTROLLER_MANAGER_OPTS = "--address = 0.0.0.0 \
--master = 127.0.0.1:8080 \
--machines = kube-minion \ -----> #this is the kubernatics node
--v = 0

次に、対応するファイルでkubeスケジューラーを構成します。

$ KUBE_SCHEDULER_OPTS = "--address = 0.0.0.0 \
--master = 127.0.0.1:8080 \
--v = 0"

上記のすべてのタスクが完了したら、Kubernetesマスターを起動して先に進むことができます。これを行うために、Dockerを再起動します。

$ service docker restart

Kubernetesノードの構成

Kubernetesノードは、 kubeletとkube-proxy の2つのサービスを実行します。先に進む前に、ダウンロードしたバイナリを、kubernetesノードを構成する必要なフォルダーにコピーする必要があります。

kubernetesマスターに対して行ったのと同じ方法でファイルをコピーします。 kubeletとkube-proxyのみを実行するため、それらを構成します。

$ cp <Path of the extracted file>/kubelet/opt/bin/
$ cp <Path of the extracted file>/kube-proxy/opt/bin/
$ cp <Path of the extracted file>/kubecfg/opt/bin/
$ cp <Path of the extracted file>/kubectl/opt/bin/
$ cp <Path of the extracted file>/kubernetes/opt/bin/

次に、コンテンツを適切なディレクトリにコピーします。

$ cp kubernetes/cluster/ubuntu/init_conf/kubelet.conf/etc/init/
$ cp kubernetes/cluster/ubuntu/init_conf/kube-proxy.conf/etc/init/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kubelet/etc/init.d/
$ cp kubernetes/cluster/ubuntu/initd_scripts/kube-proxy/etc/init.d/
$ cp kubernetes/cluster/ubuntu/default_scripts/kubelet/etc/default/
$ cp kubernetes/cluster/ubuntu/default_scripts/kube-proxy/etc/default/

*kubelet* および *kube-proxy conf* ファイルを設定します。

*/etc/init/kubelet.conf* を構成します。

$ KUBELET_OPTS = "--address = 0.0.0.0 \
--port = 10250 \
--hostname_override = kube-minion \
--etcd_servers = http://kube-master:4001 \
--enable_server = true
--v = 0"
/

kube-proxyの場合、次のコマンドを使用して構成します。

$ KUBE_PROXY_OPTS = "--etcd_servers = http://kube-master:4001 \
--v = 0"
/etc/init/kube-proxy.conf

最後に、Dockerサービスを再起動します。

$ service docker restart

これで設定は完了です。次のコマンドを実行して確認できます。

$/opt/bin/kubectl get minions

Kubernetes-画像

Kubernetes（Docker）イメージは、コンテナ化されたインフラストラクチャの主要な構成要素です。現時点では、DockerイメージをサポートするためにKubernetesのみをサポートしています。ポッドの各コンテナーには、その内部で実行されるDockerイメージがあります。

ポッドを設定するとき、設定ファイルの画像プロパティはDockerコマンドと同じ構文を持ちます。構成ファイルには、レジストリから取得する予定のイメージ名を定義するフィールドがあります。

以下は、Dockerレジストリからイメージを取得し、Kubernetesコンテナーに展開する一般的な構成構造です。

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
      containers:
         - name: neo4j-server ------------------------> 2
         image: <Name of the Docker image>----------> 3
         imagePullPolicy: Always ------------->4
         command: ["echo", "SUCCESS"] ------------------->

上記のコードでは、定義しています-

name：Tesing_for_Image_pull -この名前は、Dockerレジストリからイメージをプルした後に作成されるコンテナーの名前を識別および確認するために与えられます。
name：neo4j-server -これは、作成しようとしているコンテナに付けられた名前です。 neo4j-serverを指定したように。
image:<Dockerイメージの名前> -これは、Dockerまたはイメージの内部レジストリからプルしようとしているイメージの名前です。取得しようとしているイメージ名とともに完全なレジストリパスを定義する必要があります。
imagePullPolicy -常に-このイメージプルポリシーは、このファイルを実行してコンテナを作成するたびに、同じ名前を再びプルすることを定義します。
*コマンド：["echo"、 "SUCCESS"] *-これにより、コンテナを作成し、すべてがうまくいった場合、コンテナにアクセスするときにメッセージが表示されます。

イメージをプルしてコンテナを作成するには、次のコマンドを実行します。

$ kubectl create –f Tesing_for_Image_pull

ログを取得すると、成功として出力が取得されます。

$ kubectl log Tesing_for_Image_pull

上記のコマンドは成功の出力を生成するか、失敗として出力を取得します。

注-すべてのコマンドを自分で試すことをお勧めします。

Kubernetes-ジョブ

ジョブの主な機能は、1つ以上のポッドを作成し、ポッドの成功について追跡することです。指定された数のポッドが正常に完了することを保証します。指定された数のポッドの正常な実行が完了すると、ジョブは完了したと見なされます。

ジョブを作成する

ジョブを作成するには、次のコマンドを使用します-

apiVersion: v1
kind: Job ------------------------> 1
metadata:
   name: py
   spec:
   template:
      metadata
      name: py -------> 2
      spec:
         containers:
            - name: py ------------------------> 3
            image: python----------> 4
            command: ["python", "SUCCESS"]
            restartPocliy: Never --------> 5

上記のコードでは、定義しています-

* kind：Job→* kindをJobとして定義し、 kubectl に、使用されている yaml ファイルがジョブタイプポッドを作成することであることを伝えます。
* Name：py→*これは使用しているテンプレートの名前であり、仕様はテンプレートを定義します。
* name：py→コンテナ仕様で *py として名前を付けました。これは、そこから作成されるPodを識別するのに役立ちます。
*画像：python→*ポッド内で実行されるコンテナーを作成するためにプルする画像。
restartPolicy：Never→この画像再起動の条件はneverとして指定されます。これは、コンテナが強制終了またはfalseの場合、それ自体が再起動しないことを意味します。

次のコマンドを使用して、 py.yaml という名前で保存されたyamlでジョブを作成します。

$ kubectl create –f py.yaml

上記のコマンドはジョブを作成します。ジョブのステータスを確認する場合は、次のコマンドを使用します。

$ kubectl describe jobs/py

上記のコマンドはジョブを作成します。ジョブのステータスを確認する場合は、次のコマンドを使用します。

スケジュールされたジョブ

Kubernetesのスケジュール済みジョブは Cronetes を使用します。これはKubernetesジョブを受け取り、Kubernetesクラスターで起動します。

ジョブをスケジュールすると、指定した時点でポッドが実行されます。
自動的に起動するパロディックジョブが作成されます。

注-スケジュールされたジョブの機能はバージョン1.4でサポートされており、betch/v2alpha 1 APIは、APIサーバーを起動しながら –runtime-config = batch/v2alpha1 を渡すことで有効になります。

ジョブを作成し、スケジュールされたジョブにするために使用したのと同じyamlを使用します。

apiVersion: v1
kind: Job
metadata:
   name: py
spec:
   schedule: h/30 * * * * ? -------------------> 1
   template:
      metadata
         name: py
      spec:
         containers:
         - name: py
         image: python
         args:
/bin/sh -------> 2
-c
ps –eaf ------------> 3
restartPocliy: OnFailure

上記のコードでは、定義しています-

schedule：h/30 * * ？→ジョブが30分ごとに実行されるようにスケジュールするには。
*/bin/sh：*これは/bin/shでコンテナに入ります
* ps –eaf→*マシン上でps -eafコマンドを実行し、コンテナー内の実行中のすべてのプロセスをリストします。

このスケジュールされたジョブの概念は、指定された時点で一連のタスクをビルドして実行し、プロセスを完了するときに役立ちます。

Kubernetes-ラベルとセレクター

ラベル

ラベルは、ポッド、レプリケーションコントローラー、およびサービスに接続されるキーと値のペアです。これらは、ポッドやレプリケーションコントローラーなどのオブジェクトの属性を識別するために使用されます。それらは作成時にオブジェクトに追加でき、実行時に追加または変更できます。

セレクター

ラベルは一意性を提供しません。一般的に、多くのオブジェクトが同じラベルを保持できると言えます。ラベルセレクターは、Kubernetesのコアグループ化プリミティブです。ユーザーがオブジェクトのセットを選択するために使用します。

Kubernetes APIは現在、2種類のセレクターをサポートしています-

等価ベースのセレクター
セットベースのセレクター

等式ベースのセレクター

キーと値によるフィルタリングが可能です。一致するオブジェクトは、指定されたすべてのラベルを満たす必要があります。

セットベースのセレクター

セットベースのセレクタを使用すると、値のセットに従ってキーをフィルタリングできます。

apiVersion: v1
kind: Service
metadata:
   name: sp-neo4j-standalone
spec:
   ports:
      - port: 7474
      name: neo4j
   type: NodePort
   selector:
      app: salesplatform ---------> 1
      component: neo4j -----------> 2

上記のコードでは、ラベルセレクターを app：salesplatform として、コンポーネントを component：neo4j として使用しています。

*kubectl* コマンドを使用してファイルを実行すると、ポート7474で通信する *sp-neo4j-standalone* という名前のサービスが作成されます。 ypeは *NodePort* で、新しいラベルセレクターは *app：salesplatform* および *component：neo4j* です。

Kubernetes-名前空間

名前空間は、リソース名に追加の修飾を提供します。これは、複数のチームが同じクラスターを使用していて、名前が衝突する可能性がある場合に役立ちます。複数のクラスター間の仮想壁として使用できます。

名前空間の機能

以下は、Kubernetesのネームスペースの重要な機能の一部です-

名前空間は、同じ名前空間を使用したポッド間通信に役立ちます。
名前空間は、同じ物理クラスターの上に配置できる仮想クラスターです。
チームとその環境を論理的に分離します。

名前空間を作成する

次のコマンドは、名前空間を作成するために使用されます。

apiVersion: v1
kind: Namespce
metadata
   name: elk

名前空間を制御する

次のコマンドは、名前空間を制御するために使用されます。

$ kubectl create –f namespace.yml ---------> 1
$ kubectl get namespace -----------------> 2
$ kubectl get namespace <Namespace name> ------->3
$ kubectl describe namespace <Namespace name> ---->4
$ kubectl delete namespace <Namespace name>

上記のコードでは、

このコマンドを使用して名前空間を作成しています。
これにより、使用可能なすべてのネームスペースがリストされます。
これにより、コマンドで名前が指定された特定のネームスペースが取得されます。
これは、サービスに関する完全な詳細を説明します。
これにより、クラスターに存在する特定のネームスペースが削除されます。

サービスでのネームスペースの使用-例

以下は、サービスで名前空間を使用するためのサンプルファイルの例です。

apiVersion: v1
kind: Service
metadata:
   name: elasticsearch
   namespace: elk
   labels:
      component: elasticsearch
spec:
   type: LoadBalancer
   selector:
      component: elasticsearch
   ports:
   - name: http
      port: 9200
      protocol: TCP
   - name: transport
      port: 9300
      protocol: TCP

上記のコードでは、 elk という名前のサービスメタデータで同じ名前空間を使用しています。

Kubernetes-ノード

ノードは、ミニオンとも呼ばれるKubernetesクラスター内の作業マシンです。これらは、物理、VM、またはクラウドインスタンスの可能性がある作業単位です。

各ノードには、プロキシサービスやkubeletサービスなどのポッドを実行するために必要なすべての必要な構成があり、ノードで作成されたポッドでDockerコンテナーを実行するために使用されます。

Kubernetesによって作成されるのではなく、クラウドサービスプロバイダーまたは物理マシンまたはVMマシン上のKubernetesクラスターマネージャーによって外部で作成されます。

複数のノードを処理するKubernetesの主要なコンポーネントは、複数の種類のコントローラーを実行してノードを管理するコントローラーマネージャーです。ノードを管理するために、Kubernetesは、作成されたオブジェクトが有効なノードであることを検証する種類ノードのオブジェクトを作成します。

セレクターを使用したサービス

apiVersion: v1
kind: node
metadata:
   name: < ip address of the node>
   labels:
      name: <lable name>

JSON形式では、次のように見える実際のオブジェクトが作成されます-

{
   Kind: node
   apiVersion: v1
   "metadata":
   {
      "name": "10.01.1.10",
      "labels"
      {
         "name": "cluster 1 node"
      }
   }
}

ノードコントローラー

これらは、Kubernetesマスターで実行され、metadata.nameに基づいてクラスター内のノードを継続的に監視するサービスのコレクションです。必要なすべてのサービスが実行されている場合、ノードが検証され、コントローラーによってそのノードに新しく作成されたポッドが割り当てられます。有効でない場合、マスターはポッドを割り当てず、有効になるまで待機します。

*–register-node* フラグがtrueの場合、Kubernetesマスターはノードを自動的に登録します。

–register-node = true

ただし、クラスタ管理者が手動で管理する場合は、フラットを回すことで実行できます-

–register-node = false

Kubernetes-サービス

サービスは、ポッドの論理セットとして定義できます。これは、ポッドにアクセスできる単一のIPアドレスとDNS名を提供するポッドの上部の抽象化として定義できます。サービスを使用すると、負荷分散の構成を非常に簡単に管理できます。ポッドが非常に簡単にスケーリングできるようにします。

サービスはKubernetesのRESTオブジェクトで、その定義をKubernetesマスターのKubernetes apiServerにポストして、新しいインスタンスを作成できます。

セレクタなしのサービス

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
   targetPort: 31999

上記の構成により、Tutorial_point_serviceという名前のサービスが作成されます。

セレクターを使用したサービス構成ファイル

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   selector:
      application: "My Application" -------------------> (Selector)
   ports:
   - port: 8080
   targetPort: 31999

この例では、セレクターがあります。そのため、トラフィックを転送するには、エンドポイントを手動で作成する必要があります。

apiVersion: v1
kind: Endpoints
metadata:
   name: Tutorial_point_service
subnets:
   address:
      "ip": "192.168.168.40" -------------------> (Selector)
   ports:
      - port: 8080

上記のコードでは、「192.168.168.40:8080」として定義されたエンドポイントにトラフィックをルーティングするエンドポイントを作成しました。

マルチポートサービスの作成

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   selector:
      application: “My Application” -------------------> (Selector)
   ClusterIP: 10.3.0.12
   ports:
      -name: http
      protocol: TCP
      port: 80
      targetPort: 31999
   -name:https
      Protocol: TCP
      Port: 443
      targetPort: 31998

サービスの種類

*ClusterIP* -これは、クラスター内のサービスを制限するのに役立ちます。 定義されたKubernetesクラスター内でサービスを公開します。

spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: NodeportService

*NodePort* -展開されたノードの静的ポートでサービスを公開します。 *NodePort* サービスがルーティングする *ClusterIP* サービスが自動的に作成されます。 *NodeIP：nodePort* を使用して、クラスターの外部からサービスにアクセスできます。

spec:
   ports:
   - port: 8080
      nodePort: 31999
      name: NodeportService
      clusterIP: 10.20.30.40

ロードバランサー-クラウドプロバイダーのロードバランサーを使用します。 NodePort および ClusterIP サービスは、外部ロードバランサーがルーティングする先に自動的に作成されます。

サービスタイプがノードポートのフルサービス yaml ファイル。自分で作成してみてください。

apiVersion: v1
kind: Service
metadata:
   name: appname
   labels:
      k8s-app: appname
spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: omninginx
   selector:
      k8s-app: appname
      component: nginx
      env: env_name

Kubernetes-ポッド

ポッドは、Kubernetesクラスターのノード内のコンテナーとそのストレージのコレクションです。内部に複数のコンテナを持つポッドを作成することが可能です。たとえば、データベースコンテナーとデータコンテナーを同じポッドに保持します。

ポッドの種類

ポッドには2種類あります-

シングルコンテナポッド
マルチコンテナポッド

シングルコンテナポッド

これらはkubctl runコマンドを使用して簡単に作成できます。このコマンドでは、ポッドの作成中にプルするDockerレジストリに定義済みのイメージがあります。

$ kubectl run <name of pod> --image=<name of the image from registry>

例-Dockerハブで利用可能なTomcatイメージでポッドを作成します。

$ kubectl run tomcat --image = tomcat:8.0

これは、 yaml ファイルを作成してから kubectl create コマンドを実行することでも実行できます。

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
    image: tomcat: 8.0
    ports:
containerPort: 7500
   imagePullPolicy: Always

上記の yaml ファイルが作成されたら、 tomcat.yml という名前でファイルを保存し、作成コマンドを実行してドキュメントを実行します。

$ kubectl create –f tomcat.yml

tomcatという名前のポッドが作成されます。 describeコマンドと kubectl を使用してポッドを説明できます。

マルチコンテナポッド

マルチコンテナポッドは、コンテナの定義で yaml mail を使用して作成されます。

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
    image: tomcat: 8.0
    ports:
containerPort: 7500
   imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
containerPort: 7501
   imagePullPolicy: Always

上記のコードでは、Tomcat用とMongoDB用の2つのコンテナを持つ1つのポッドを作成しました。

Kubernetes-レプリケーションコントローラー

レプリケーションコントローラーは、Kubernetesの重要な機能の1つであり、ポッドのライフサイクルを管理します。指定された数のポッドレプリカがいつでも実行されていることを確認する必要があります。指定された数のポッドまたは少なくとも1つのポッドが実行されていることを確認したいときに使用します。指定されたnoのポッドをアップまたはダウンする機能があります。

ポッドを何度も作成するのではなく、複製コントローラーを使用してポッドのライフサイクルを管理することをお勧めします。

apiVersion: v1
kind: ReplicationController --------------------------> 1
metadata:
   name: Tomcat-ReplicationController --------------------------> 2
spec:
   replicas: 3 ------------------------> 3
   template:
      metadata:
         name: Tomcat-ReplicationController
      labels:
         app: App
         component: neo4j
      spec:
         containers:
         - name: Tomcat- -----------------------> 4
         image: tomcat: 8.0
         ports:
            - containerPort: 7474 ------------------------> 5

セットアップの詳細

種類：ReplicationController *→上記のコードでは、 *yabe ファイルがレプリケーションコントローラーの作成に使用されることを kubectl に伝えるレプリケーションコントローラーとして種類を定義しています。
name：Tomcat-ReplicationController →これは、複製コントローラーが作成される名前を識別するのに役立ちます。 kubctlを実行すると、 rc <Tomcat-ReplicationController> を取得すると、レプリケーションコントローラーの詳細が表示されます。
replicas：3 →これにより、複製コントローラーは、ポッドのライフサイクルの任意の時点でポッドの3つのレプリカを維持する必要があることを理解できます。
*名前：Tomcat *→仕様セクションでは、ポッド内に存在するコンテナがtomcatであることをレプリケーションコントローラーに伝えるtomcatとして名前を定義しています。
containerPort：7474 →ポッドがポッド内のコンテナーを実行しているクラスター内のすべてのノードが同じポート7474で公開されるようにするのに役立ちます。

Kube Service for Replicas

ここでは、Kubernetesサービスが3つのTomcatレプリカのロードバランサーとして機能しています。

Kubernetes-レプリカセット

レプリカセットは、ポッドのレプリカの数を実行する必要があります。レプリケーションコントローラーの代替と見なすことができます。レプリカセットと複製コントローラーの主な違いは、複製コントローラーが等式ベースのセレクターのみをサポートするのに対して、レプリカセットはセットベースのセレクターをサポートすることです。

apiVersion: extensions/v1beta1 --------------------->1
kind: ReplicaSet --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
         tier: Backend ------------------> 3
      matchExpression:
{ key: tier, operation: In, values: [Backend]} --------------> 4
template:
   metadata:
      lables:
         app: Tomcat-ReplicaSet
         tier: Backend
      labels:
         app: App
         component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

セットアップの詳細

apiVersion：extensions/v1beta1 →上記のコードでは、APIバージョンはレプリカセットの概念をサポートするKubernetesの高度なベータバージョンです。
kind：ReplicaSet →kubectlがファイルがレプリカセットの作成に使用されていることを理解するのに役立つレプリカセットとして種類を定義しました。
層：バックエンド→ラベル層を、一致するセレクターを作成するバックエンドとして定義しました。
\ {key：tier、operation：In、values：[Backend]} →これは、 matchExpression が定義した一致条件を理解し、 matchlabel が詳細を見つけるために使用する操作で理解するのに役立ちます。
```
*kubectl* を使用して上記のファイルを実行し、 *yaml* ファイルで指定された定義を使用してバックエンドレプリカセットを作成します。
```

Kube Serviceバックエンドレプリカセット

Kubernetes-展開

展開がアップグレードされ、レプリケーションコントローラーの上位バージョン。これらは、複製コントローラのアップグレードバージョンでもあるレプリカセットの展開を管理します。レプリカセットを更新する機能があり、以前のバージョンにロールバックすることもできます。

これらは、 matchLabels および selectors の多くの更新された機能を提供します。 Kubernetesマスターには、それを実現する展開コントローラーと呼ばれる新しいコントローラーがあります。展開を途中で変更する機能があります。

展開の変更

更新中-ユーザーは進行中の展開を完了する前に更新できます。これにより、既存の展開が解決され、新しい展開が作成されます。

削除-ユーザーは、展開を完了する前に削除することで、展開を一時停止/キャンセルできます。同じデプロイメントを再作成すると、再開されます。

ロールバック-展開または展開中の展開をロールバックできます。ユーザーは、* DeploymentSpec.PodTemplateSpec = oldRC.PodTemplateSpec。*を使用して、展開を作成または更新できます。

展開戦略

展開戦略は、新しいRCが既存のRCを置き換える方法を定義するのに役立ちます。

再作成-この機能は、既存のすべてのRCを強制終了し、新しいRCを表示します。これにより、迅速な展開が可能になりますが、古いポッドがダウンし、新しいポッドが起動しない場合、ダウンタイムが発生します。

ローリングアップデート-この機能は、古いRCを徐々にダウンさせ、新しいRCをアップさせます。これにより、展開が遅くなりますが、展開はありません。常に、このプロセスで使用できる古いポッドと新しいポッドはほとんどありません。

Deploymentの構成ファイルは次のようになります。

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
         lables:
            app: Tomcat-ReplicaSet
            tier: Backend
   spec:
      containers:
         - name: Tomcatimage:
            tomcat: 8.0
            ports:
               - containerPort: 7474

上記のコードでは、レプリカセットと異なるのは、種類を展開として定義したことだけです。

配置を作成

$ kubectl create –f Deployment.yaml -–record
deployment "Deployment" created Successfully.

展開を取得する

$ kubectl get deployments
NAME           DESIRED     CURRENT     UP-TO-DATE     AVILABLE    AGE
Deployment        3           3           3              3        20s

展開のステータスを確認する

$ kubectl rollout status deployment/Deployment

展開の更新

$ kubectl set image deployment/Deployment tomcat=tomcat:6.0

前の展開へのロールバック

$ kubectl rollout undo deployment/Deployment –to-revision=2

Kubernetes-ボリューム

Kubernetesでは、ボリュームはポッド内のコンテナーからアクセス可能なディレクトリと考えることができます。 Kubernetesにはさまざまなタイプのボリュームがあり、タイプはボリュームの作成方法とそのコンテンツを定義します。

Dockerにはボリュームの概念がありましたが、唯一の問題はボリュームが特定のポッドに非常に限定されていたことでした。ポッドの寿命が終了するとすぐに、ボリュームも失われました。

一方、Kubernetesを介して作成されるボリュームは、コンテナーに限定されません。 Kubernetesのポッド内に展開されたコンテナの一部またはすべてをサポートします。 Kubernetesボリュームの主な利点は、ポッドが複数のストレージを同時に使用できる異なる種類のストレージをサポートしていることです。

Kubernetesボリュームの種類

以下は、人気のあるKubernetesボリュームのリストです-

emptyDir -ポッドがノードに最初に割り当てられたときに作成されるタイプのボリュームです。 Podがそのノードで実行されている限り、アクティブのままです。ボリュームは最初は空であり、ポッド内のコンテナーはemptyDirボリューム内のファイルを読み書きできます。ノードからポッドが削除されると、emptyDirのデータは消去されます。
hostPath -このタイプのボリュームは、ホストノードのファイルシステムからポッドにファイルまたはディレクトリをマウントします。
gcePersistentDisk -このタイプのボリュームは、Google Compute Engine（GCE）永続ディスクをポッドにマウントします。ポッドがノードから削除されても、 gcePersistentDisk のデータはそのまま残ります。
awsElasticBlockStore -このタイプのボリュームは、Amazon Web Services（AWS）Elastic Block Storeをポッドにマウントします。 gcePersistentDisk と同様に、 awsElasticBlockStore のデータは、ポッドがノードから削除されてもそのまま残ります。
nfs - nfs ボリュームを使用すると、既存のNFS（ネットワークファイルシステム）をポッドにマウントできます。ノードからポッドが削除されても、 nfs ボリュームのデータは消去されません。ボリュームはアンマウントされているだけです。
iscsi - iscsi ボリュームにより、既存のiSCSI（SCSI over IP）ボリュームをポッドにマウントできます。
flocker -これは、オープンソースのクラスター化コンテナーデータボリュームマネージャーです。データボリュームの管理に使用されます。 flocker ボリュームを使用すると、Flockerデータセットをポッドにマウントできます。データセットがFlockerに存在しない場合、まずFlocker APIを使用して作成する必要があります。
glusterfs -Glusterfsは、オープンソースのネットワークファイルシステムです。 glusterfsボリュームを使用すると、glusterfsボリュームをポッドにマウントできます。
rbd -RBDはRados Block Deviceの略です。 rbd ボリュームを使用すると、Rados Block Deviceボリュームをポッドにマウントできます。ノードからポッドが削除された後も、データは保持されたままです。
cephfs - cephfs ボリュームを使用すると、既存のCephFSボリュームをポッドにマウントできます。ポッドがノードから削除された後、データはそのまま残ります。
gitRepo - gitRepo ボリュームは空のディレクトリをマウントし、ポッドが使用する git リポジトリをそこにクローンします。
secret - secret ボリュームは、パスワードなどの機密情報をポッドに渡すために使用されます。
persistentVolumeClaim - persistentVolumeClaim ボリュームは、PersistentVolumeをポッドにマウントするために使用されます。 PersistentVolumesは、特定のクラウド環境の詳細を知らなくても、ユーザーが永続ストレージ（GCE PersistentDiskやiSCSIボリュームなど）を「要求」する方法です。
downwardAPI - downwardAPI ボリュームを使用して、アプリケーションで下位APIデータを利用できるようにします。ディレクトリをマウントし、要求されたデータをプレーンテキストファイルに書き込みます。
azureDiskVolume - AzureDiskVolume は、Microsoft Azureデータディスクをポッドにマウントするために使用されます。

永続ボリュームと永続ボリューム要求

永続ボリューム（PV）-管理者によってプロビジョニングされたネットワークストレージです。これは、PVを使用する個々のポッドから独立したクラスター内のリソースです。

Persistent Volume Claim（PVC）*-Kubernetesがポッド用に要求するストレージは、PVCと呼ばれます。ユーザーは、基礎となるプロビジョニングを知る必要はありません。クレームは、ポッドが作成されるのと同じネームスペースで作成する必要があります。

永続ボリュームの作成

kind: PersistentVolume ---------> 1
apiVersion: v1
metadata:
   name: pv0001 ------------------> 2
   labels:
      type: local
spec:
   capacity: -----------------------> 3
      storage: 10Gi ----------------------> 4
   accessModes:
      - ReadWriteOnce -------------------> 5
      hostPath:
         path: "/tmp/data01" --------------------------> 6

上記のコードでは、定義しています-

kind：PersistentVolume →使用されているyamlファイルが永続ボリュームを作成することであることをkubernetesに伝えるPersistentVolumeとして種類を定義しました。
name：pv0001 →作成しているPersistentVolumeの名前。
容量：→この仕様は、作成しようとしているPVの容量を定義します。
storage：10Gi →これは、定義されたパス上の10Giスペースを要求しようとしていることを、基盤となるインフラストラクチャに伝えます。
ReadWriteOnce →これは、作成しているボリュームのアクセス権を示します。
path： "/tmp/data01" →この定義は、基礎となるインフラストラクチャ上のこのパスの下にボリュームを作成しようとしていることをマシンに伝えます。

PVの作成

$ kubectl create –f local-01.yaml
persistentvolume "pv0001" created

PVの確認

$ kubectl get pv
NAME        CAPACITY      ACCESSMODES       STATUS       CLAIM      REASON     AGE
pv0001        10Gi            RWO         Available                            14s

PVの説明

$ kubectl describe pv pv0001

永続的なボリューム要求の作成

kind: PersistentVolumeClaim --------------> 1
apiVersion: v1
metadata:
   name: myclaim-1 --------------------> 2
spec:
   accessModes:
      - ReadWriteOnce ------------------------> 3
   resources:
      requests:
         storage: 3Gi ---------------------> 4

上記のコードでは、定義しています-

kind：PersistentVolumeClaim →指定された容量を要求しようとしている基盤インフラストラクチャに指示します。
name：myclaim-1 →作成しようとしているクレームの名前。
ReadWriteOnce →これは、作成しようとしているクレームのモードを指定します。
*ストレージ：3Gi *→これにより、kubernetesに要求しようとしているスペースの量が通知されます。

PVCの作成

$ kubectl create –f myclaim-1
persistentvolumeclaim "myclaim-1" created

PVCに関する詳細の取得

$ kubectl get pvc
NAME        STATUS   VOLUME   CAPACITY   ACCESSMODES   AGE
myclaim-1   Bound    pv0001     10Gi         RWO       7s

PVCの説明

$ kubectl describe pv pv0001

PODでPVおよびPVCを使用する

kind: Pod
apiVersion: v1
metadata:
   name: mypod
   labels:
      name: frontendhttp
spec:
   containers:
   - name: myfrontend
      image: nginx
      ports:
      - containerPort: 80
         name: "http-server"
      volumeMounts: ----------------------------> 1
      - mountPath: "/usr/share/tomcat/html"
         name: mypd
   volumes: -----------------------> 2
      - name: mypd
         persistentVolumeClaim: ------------------------->3
         claimName: myclaim-1

上記のコードでは、定義しています-

* volumeMounts：*→これは、マウントが行われるコンテナ内のパスです。
ボリューム：→この定義は、クレームするボリューム定義を定義します。
* persistentVolumeClaim：*→この下で、定義されたポッドで使用するボリューム名を定義します。

Kubernetes-秘密

シークレットは、暗号化されたユーザー名やパスワードなどの機密データの保存に使用されるKubernetesオブジェクトとして定義できます。

Kubernetesでシークレットを作成する方法は複数あります。

txtファイルから作成します。
yamlファイルから作成します。

テキストファイルから作成

ユーザー名やパスワードなどのテキストファイルからシークレットを作成するには、まずそれらをtxtファイルに保存し、次のコマンドを使用する必要があります。

$ kubectl create secret generic tomcat-passwd –-from-file = ./username.txt –fromfile = ./.
password.txt

Yamlファイルから作成する

apiVersion: v1
kind: Secret
metadata:
name: tomcat-pass
type: Opaque
data:
   password: <User Password>
   username: <User Name>

シークレットを作成する

$ kubectl create –f Secret.yaml
secrets/tomcat-pass

シークレットを使用する

シークレットを作成したら、ポッドまたはレプリケーションコントローラーで次のように使用できます-

環境変数
ボリューム

環境変数として

環境変数としてシークレットを使用するために、ポッドyamlファイルのspecセクションで env を使用します。

env:
- name: SECRET_USERNAME
   valueFrom:
      secretKeyRef:
         name: mysecret
         key: tomcat-pass

ボリュームとして

spec:
   volumes:
      - name: "secretstest"
         secret:
            secretName: tomcat-pass
   containers:
      - image: tomcat:7.0
         name: awebserver
         volumeMounts:
            - mountPath: "/tmp/mysec"
            name: "secretstest"

環境変数としての秘密の構成

apiVersion: v1
kind: ReplicationController
metadata:
   name: appname
spec:
replicas: replica_count
template:
   metadata:
      name: appname
   spec:
      nodeSelector:
         resource-group:
      containers:
         - name: appname
            image:
            imagePullPolicy: Always
            ports:
            - containerPort: 3000
            env: -----------------------------> 1
               - name: ENV
                  valueFrom:
                     configMapKeyRef:
                        name: appname
                        key: tomcat-secrets

上記のコードでは、 env 定義の下で、レプリケーションコントローラーの環境変数としてシークレットを使用しています。

ボリュームマウントとしての秘密

apiVersion: v1
kind: pod
metadata:
   name: appname
spec:
   metadata:
      name: appname
   spec:
   volumes:
      - name: "secretstest"
         secret:
            secretName: tomcat-pass
   containers:
      - image: tomcat: 8.0
         name: awebserver
         volumeMounts:
            - mountPath: "/tmp/mysec"
            name: "secretstest"

Kubernetes-ネットワークポリシー

ネットワークポリシーは、同じ名前空間内のポッドが相互におよびネットワークエンドポイントと通信する方法を定義します。 APIサーバーのランタイム構成で extensions/v1beta1/networkpolicies を有効にする必要があります。そのリソースは、ラベルを使用してポッドを選択し、ルールを定義して、ネームスペースで定義されている特定のポッドへのトラフィックを許可します。

まず、名前空間分離ポリシーを構成する必要があります。基本的に、この種のネットワークポリシーはロードバランサーに必要です。

kind: Namespace
apiVersion: v1
metadata:
   annotations:
      net.beta.kubernetes.io/network-policy: |
      {
         "ingress":
         {
            "isolation": "DefaultDeny"
         }
      }

$ kubectl annotate ns <namespace> "net.beta.kubernetes.io/network-policy =
{\"ingress\": {\"isolation\": \"DefaultDeny\"}}"

名前空間を作成したら、ネットワークポリシーを作成する必要があります。

ネットワークポリシーYaml

kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
   name: allow-frontend
   namespace: myns
spec:
   podSelector:
      matchLabels:
         role: backend
   ingress:
   - from:
      - podSelector:
         matchLabels:
            role: frontend
   ports:
      - protocol: TCP
         port: 6379

Kubernetes-API

Kubernetes APIは、システムの宣言的な構成スキーマの基盤として機能します。 Kubectl コマンドラインツールを使用して、APIオブジェクトを作成、更新、削除、および取得できます。 Kubernetes APIは、Kubernetesのさまざまなコンポーネント間でコミュニケーターとして機能します。

KubernetesにAPIを追加する

Kubernetesに新しいAPIを追加すると、Kubernetesに新しい機能が追加され、Kubernetesの機能が向上します。ただし、システムのコストと保守性も増加します。コストと複雑さのバランスをとるために、いくつかのセットが定義されています。

追加されるAPIは、ユーザーの50％以上に役立つはずです。 Kubernetesに機能を実装する他の方法はありません。例外的な状況については、Kubernetesのコミュニティミーティングで説明し、APIを追加します。

APIの変更

Kubernetesの機能を向上させるために、システムに継続的に変更が導入されます。 Kubernetesチームは、システムの既存の機能を削除したり、影響を与えたりせずにKubernetesに機能を追加します。

一般的なプロセスを実証するために、ここに（仮説的な）例があります-

ユーザーがPodオブジェクトを*/api/v7beta1/…*にPOSTします
JSONは v7beta1.Pod 構造に非整列化されます
デフォルト値は v7beta1.Pod に適用されます
v7beta1.Pod は api.Pod 構造に変換されます
api.Pod が検証され、すべてのエラーがユーザーに返されます
api.Pod はv6.Podに変換されます（v6は最新の安定バージョンであるため）
v6.Pod はJSONにマーシャリングされ、 etcd に書き込まれます

Podオブジェクトが保存されたので、ユーザーはサポートされている任意のAPIバージョンでそのオブジェクトを取得できます。たとえば-

ユーザーは*/api/v5/…*からポッドを取得します
JSONは etcd および unmarshalled から v6.Pod 構造に読み取られます
デフォルト値は v6.Pod に適用されます
v6.Pod はapi.Pod構造に変換されます
api.Pod は v5.Pod 構造に変換されます
v5.Pod はJSONにマーシャリングされ、ユーザーに送信されます

このプロセスの意味するところは、APIの変更は慎重にかつ下位互換性を持って行う必要があるということです。

APIバージョン管理

複数の構造のサポートを容易にするために、Kubernetesは、 /api/v1 または /apsi/extensions/v1beta1 などの異なるAPIパスで複数のAPIバージョンをサポートします

Kubernetesのバージョニング標準は、複数の標準で定義されています。

アルファレベル

このバージョンにはアルファが含まれています（例： v1alpha1）
このバージョンはバグがあるかもしれません。有効なバージョンにはバグがある可能性があります
バグのサポートはいつでも削除できます。
サポートが常に存在しない場合があるため、短期テストでのみ使用することをお勧めします。

ベータレベル

バージョン名にベータ版が含まれています（例： v2beta3）
コードは完全にテストされており、有効なバージョンは安定しているはずです。
この機能のサポートは廃止されません。いくつかの小さな変更があるかもしれません。
以降のリリースで互換性のない変更が行われる可能性があるため、ビジネスクリティカルではない使用にのみ推奨されます。

安定したレベル

バージョン名は vX です。 X は整数です。
機能の安定したバージョンは、多くの後続バージョンのリリースされたソフトウェアに表示されます。

Kubernetes-Kubectl

Kubectlは、Kubernetes APIと対話するためのコマンドラインユーティリティです。これは、Kubernetesクラスター内のポッドの通信と管理に使用されるインターフェースです。

Kubernetesクラスターと対話するには、kubectlをローカルに設定する必要があります。

Kubectlの設定

curlコマンドを使用して、実行可能ファイルをローカルワークステーションにダウンロードします。

Linuxの場合

$ curl -O https://storage.googleapis.com/kubernetesrelease/
release/v1.5.2/bin/linux/amd64/kubectl

OS Xワークステーション上

$ curl -O https://storage.googleapis.com/kubernetesrelease/
release/v1.5.2/bin/darwin/amd64/kubectl

ダウンロードが完了したら、システムのパスでバイナリを移動します。

$ chmod +x kubectl
$ mv kubectl/usr/local/bin/kubectl

Kubectlの構成

構成操作を実行する手順は次のとおりです。

$ kubectl config set-cluster default-cluster --server = https://${MASTER_HOST} --
certificate-authority = ${CA_CERT}

$ kubectl config set-credentials default-admin --certificateauthority = ${
CA_CERT} --client-key = ${ADMIN_KEY} --clientcertificate = ${
ADMIN_CERT}

$ kubectl config set-context default-system --cluster = default-cluster --
user = default-admin
$ kubectl config use-context default-system

$ \ {MASTER_HOST} を、前の手順で使用したマスターノードのアドレスまたは名前に置き換えます。
$ \ {CA_CERT} を前の手順で作成した ca.pem への絶対パスに置き換えます。
$ \ {ADMIN_KEY} を前の手順で作成した admin-key.pem への絶対パスに置き換えます。
$ \ {ADMIN_CERT} を前の手順で作成した admin.pem への絶対パスに置き換えます。

セットアップの検証

*kubectl* が正常に動作しているかどうかを確認するには、Kubernetesクライアントが正しくセットアップされているかどうかを確認します。

$ kubectl get nodes

NAME       LABELS                                     STATUS
Vipin.com  Kubernetes.io/hostname = vipin.mishra.com    Ready

Kubernetes-Kubectlコマンド

*Kubectl* はKubernetesクラスターを制御します。 これは、セットアップが完了したときに任意のマシンのワークステーションで実行されるKubernetesの重要なコンポーネントの1つです。 クラスタ内のノードを管理する機能があります。

*Kubectl* コマンドは、Kubernetesオブジェクトとクラスターの対話と管理に使用されます。 この章では、kubernetesでkubectlを介して使用されるいくつかのコマンドについて説明します。

*kubectl annotate* -リソースの注釈を更新します。

$kubectl annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ...
KEY_N = VAL_N [--resource-version = version]

例えば、

kubectl annotate pods tomcat description = 'my frontend'

*kubectl api-versions* -クラスタ上のAPIのサポートされているバージョンを出力します。

$ kubectl api-version;

*kubectl apply* -ファイルまたはstdinでリソースを設定する機能があります。

$ kubectl apply –f <filename>

*kubectl attach* -これは実行中のコンテナに物を添付します。

$ kubectl attach <pod> –c <container>
$ kubectl attach 123456-7890 -c tomcat-conatiner

*kubectl autoscale* -これは、展開、レプリカセット、レプリケーションコントローラーなどのポッドの自動スケーリングに使用されます。

$ kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min = MINPODS] --
max = MAXPODS [--cpu-percent = CPU] [flags]
$ kubectl autoscale deployment foo --min = 2 --max = 10

*kubectl cluster-info* -クラスタ情報を表示します。

$ kubectl cluster-info

*kubectl cluster-info dump* -デバッグと診断のためにクラスターに関する関連情報をダンプします。

$ kubectl cluster-info dump
$ kubectl cluster-info dump --output-directory =/path/to/cluster-state

*kubectl config* -kubeconfigファイルを変更します。

$ kubectl config <SUBCOMMAD>
$ kubectl config –-kubeconfig <String of File name>

*kubectl config current-context* -現在のコンテキストを表示します。

$ kubectl config current-context
#deploys the current context

*kubectl config delete-cluster* -指定されたクラスターをkubeconfigから削除します。

$ kubectl config delete-cluster <Cluster Name>

*kubectl config delete-context* -指定されたコンテキストをkubeconfigから削除します。

$ kubectl config delete-context <Context Name>

*kubectl config get-clusters* -kubeconfigで定義されたクラスターを表示します。

$ kubectl config get-cluster
$ kubectl config get-cluster <Cluser Name>

*kubectl config get-contexts* -1つまたは複数のコンテキストについて説明します。

$ kubectl config get-context <Context Name>

*kubectl config set-cluster* -Kubernetesでクラスターエントリを設定します。

$ kubectl config set-cluster NAME [--server = server] [--certificateauthority =
path/to/certificate/authority] [--insecure-skip-tls-verify = true]

*kubectl config set-context* -kubernetesエントリポイントにコンテキストエントリを設定します。

$ kubectl config set-context NAME [--cluster = cluster_nickname] [--
user = user_nickname] [--namespace = namespace]
$ kubectl config set-context prod –user = vipin-mishra

*kubectl config set-credentials* -kubeconfigでユーザーエントリを設定します。

$ kubectl config set-credentials cluster-admin --username = vipin --
password = uXFGweU9l35qcif

*kubectl config set* -kubeconfigファイルに個々の値を設定します。

$ kubectl config set PROPERTY_NAME PROPERTY_VALUE

*kubectl config unset* -kubectlで特定のコンポーネントの設定を解除します。

$ kubectl config unset PROPERTY_NAME PROPERTY_VALUE

*kubectl config use-context* -kubectlファイルの現在のコンテキストを設定します。

$ kubectl config use-context <Context Name>

*kubectl config view*

$ kubectl config view
$ kubectl config view –o jsonpath='{.users[?(@.name == "e2e")].user.password}'

*kubectl cp* -ファイルとディレクトリをコンテナ間でコピーします。

$ kubectl cp <Files from source> <Files to Destinatiion>
$ kubectl cp/tmp/foo <some-pod>:/tmp/bar -c <specific-container>

*kubectl create* -またはstdinのファイル名でリソースを作成します。 これを行うために、JSONまたはYAML形式が受け入れられます。

$ kubectl create –f <File Name>
$ cat <file name> | kubectl create –f -

同じ方法で、 create コマンドと kubectl を使用して、リストされているように複数のものを作成できます。

配備
名前空間
クォータ
秘密のドッカーレジストリ
秘密の
秘密のジェネリック
秘密のTL
サービスアカウント
サービスclusterip
サービスロードバランサー

サービスノードポート

*kubectl delete* -ファイル名、標準入力、リソース、名前でリソースを削除します。

$ kubectl delete –f ([-f FILENAME] | TYPE [(NAME | -l label | --all)])

*kubectl describe* -kubernetesの特定のリソースについて説明します。 リソースまたはリソースのグループの詳細を表示します。

$ kubectl describe <type> <type name>
$ kubectl describe pod tomcat

*kubectl drain* -これは、メンテナンス目的でノードを排出するために使用されます。 メンテナンスのためにノードを準備します。 これにより、ノードが使用不可としてマークされ、作成される新しいコンテナに割り当てられなくなります。

$ kubectl drain tomcat –force

*kubectl edit* -サーバー上のリソースを終了するために使用されます。 これにより、コマンドラインツールを介して受け取ることができるリソースを直接編集できます。

$ kubectl edit <Resource/Name | File Name)
Ex.
$ kubectl edit rc/tomcat

*kubectl exec* -これはコンテナでコマンドを実行するのに役立ちます。

$ kubectl exec POD <-c CONTAINER > -- COMMAND < args...>
$ kubectl exec tomcat 123-5-456 date

*kubectl expose* -これは、ポッド、レプリケーションコントローラー、サービスなどのKubernetesオブジェクトを新しいKubernetesサービスとして公開するために使用されます。 これには、実行中のコンテナまたは *yaml* ファイルから公開する機能があります。

$ kubectl expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol = TCP|UDP]
[--target-port = number-or-name] [--name = name] [--external-ip = external-ip-ofservice]
[--type = type]
$ kubectl expose rc tomcat –-port=80 –target-port = 30000
$ kubectl expose –f tomcat.yaml –port = 80 –target-port =

*kubectl get* -このコマンドは、Kubernetesリソースに関するクラスター上のデータを取得できます。

$ kubectl get [(-o|--output=)json|yaml|wide|custom-columns=...|custom-columnsfile=...|
go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...]
(TYPE [NAME | -l label] | TYPE/NAME ...) [flags]

例えば、

$ kubectl get pod <pod name>
$ kubectl get service <Service name>

*kubectl logs* -ポッド内のコンテナのログを取得するために使用されます。 ログを印刷すると、ポッドでコンテナー名を定義できます。 PODにコンテナが1つしかない場合、その名前を定義する必要はありません。

$ kubectl logs [-f] [-p] POD [-c CONTAINER]
Example
$ kubectl logs tomcat.
$ kubectl logs –p –c tomcat.8

*kubectl port-forward* -1つまたは複数のローカルポートをポッドに転送するために使用されます。

$ kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT
[...[LOCAL_PORT_N:]REMOTE_PORT_N]
$ kubectl port-forward tomcat 3000 4000
$ kubectl port-forward tomcat 3000:5000

*kubectl replace* -リソースをファイル名または *stdin* で置き換えることができます。

$ kubectl replace -f FILENAME
$ kubectl replace –f tomcat.yml
$ cat tomcat.yml | kubectl replace –f -

*kubectl rolling-update* -複製コントローラーでローリング更新を実行します。 一度にPODを更新することにより、指定された複製コントローラーを新しい複製コントローラーに置き換えます。

$ kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --
image = NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC)
$ kubectl rolling-update frontend-v1 –f freontend-v2.yaml

*kubectl rollout* -展開のロールアウトを管理できます。

$ Kubectl rollout <Sub Command>
$ kubectl rollout undo deployment/tomcat

上記とは別に、次のようなロールアウトを使用して複数のタスクを実行できます-

ロールアウト履歴
ロールアウト一時停止
ロールアウト再開
ロールアウトステータス

ロールアウトの取り消し

*kubectl run* -Runコマンドには、Kubernetesクラスターでイメージを実行する機能があります。

$ kubectl run NAME --image = image [--env = "key = value"] [--port = port] [--
replicas = replicas] [--dry-run = bool] [--overrides = inline-json] [--command] --
[COMMAND] [args...]
$ kubectl run tomcat --image = tomcat:7.0
$ kubectl run tomcat –-image = tomcat:7.0 –port = 5000

*kubectl scale* -Kubernetes Deployments、ReplicaSet、Replication Controller、またはジョブのサイズをスケーリングします。

$ kubectl scale [--resource-version = version] [--current-replicas = count] --
replicas = COUNT (-f FILENAME | TYPE NAME )
$ kubectl scale –-replica = 3 rs/tomcat
$ kubectl scale –replica = 3 tomcat.yaml

*kubectl set image* -ポッドテンプレートのイメージを更新します。

$ kubectl set image (-f FILENAME | TYPE NAME)
CONTAINER_NAME_1 = CONTAINER_IMAGE_1 ... CONTAINER_NAME_N = CONTAINER_IMAGE_N
$ kubectl set image deployment/tomcat busybox = busybox ngnix = ngnix:1.9.1
$ kubectl set image deployments, rc tomcat = tomcat6.0 --all

*kubectl set resources* -リソースのコンテンツを設定するために使用されます。 ポッドテンプレートを使用して、オブジェクトのリソース/制限を更新します。

$ kubectl set resources (-f FILENAME | TYPE NAME) ([--limits = LIMITS & --
requests = REQUESTS]
$ kubectl set resources deployment tomcat -c = tomcat --
limits = cpu = 200m,memory = 512Mi

*kubectl top node* -CPU/メモリ/ストレージの使用状況を表示します。 topコマンドを使用すると、ノードのリソース消費を確認できます。

$ kubectl top node [node Name]

同じコマンドをポッドでも使用できます。

Kubernetes-アプリの作成

Kubernetes展開用のアプリケーションを作成するには、最初にDockerでアプリケーションを作成する必要があります。これは2つの方法で行うことができます-

ダウンロードすることにより *Dockerファイルから

ダウンロードすることにより

既存のイメージはDockerハブからダウンロードでき、ローカルのDockerレジストリに保存できます。

そのためには、Docker* pull *コマンドを実行します。

$ docker pull --help
Usage: docker pull [OPTIONS] NAME[:TAG|@DIGEST]
Pull an image or a repository from the registry
   -a, --all-tags = false     Download all tagged images in the repository
   --help = false             Print usage

上記のコードの出力は次のとおりです。

アプリ出力

上記のスクリーンショットは、ローカルDockerレジストリに保存されている一連の画像を示しています。

テストするアプリケーションで構成されるイメージからコンテナを構築する場合は、Docker runコマンドを使用して実行できます。

$ docker run –i –t unbunt/bin/bash

Dockerファイルから

Dockerファイルからアプリケーションを作成するには、まずDockerファイルを作成する必要があります。

以下は、Jenkins Dockerファイルの例です。

FROM ubuntu:14.04
MAINTAINER [email protected]
ENV REFRESHED_AT 2017-01-15
RUN apt-get update -qq && apt-get install -qqy curl
RUN curl https://get.docker.io/gpg | apt-key add -
RUN echo deb http://get.docker.io/ubuntu docker main >/etc/apt/↩
sources.list.d/docker.list
RUN apt-get update -qq && apt-get install -qqy iptables ca-↩
certificates lxc openjdk-6-jdk git-core lxc-docker
ENV JENKINS_HOME/opt/jenkins/data
ENV JENKINS_MIRROR http://mirrors.jenkins-ci.org
RUN mkdir -p $JENKINS_HOME/plugins
RUN curl -sf -o/opt/jenkins/jenkins.war -L $JENKINS_MIRROR/war-↩
stable/latest/jenkins.war
RUN for plugin in chucknorris greenballs scm-api git-client git ↩
ws-cleanup ;\
do curl -sf -o $JENKINS_HOME/plugins/${plugin}.hpi \
-L $JENKINS_MIRROR/plugins/${plugin}/latest/${plugin}.hpi ↩
; done
ADD ./dockerjenkins.sh/usr/local/bin/dockerjenkins.sh
RUN chmod +x/usr/local/bin/dockerjenkins.sh
VOLUME/var/lib/docker
EXPOSE 8080
ENTRYPOINT [ "/usr/local/bin/dockerjenkins.sh" ]

上記のファイルが作成されたら、Dockerfileという名前で保存し、ファイルパスにcdします。次に、次のコマンドを実行します。

コマンドの実行

$ sudo docker build -t jamtur01/Jenkins .

イメージが構築されたら、イメージが正常に機能し、コンテナに変換できるかどうかをテストできます。

$ docker run –i –t jamtur01/Jenkins/bin/bash

Kubernetes-アプリの展開

デプロイメントは、イメージをコンテナに変換し、それらのイメージをKubernetesクラスター内のポッドに割り当てる方法です。これは、サービス、ポッド、レプリケーションコントローラー、レプリカセットの展開を含むアプリケーションクラスターのセットアップにも役立ちます。クラスタは、ポッドにデプロイされたアプリケーションが相互に通信できるようにセットアップできます。

このセットアップでは、1つのアプリケーションの上にロードバランサーを設定して、トラフィックをポッドのセットに転送し、後でバックエンドポッドと通信できます。ポッド間の通信は、Kubernetesで構築されたサービスオブジェクトを介して行われます。

アプリケーションクラスタービュー

NgnixロードバランサーYamlファイル

apiVersion: v1
kind: Service
metadata:
   name: oppv-dev-nginx
      labels:
         k8s-app: omni-ppv-api
spec:
   type: NodePort
   ports:
   - port: 8080
      nodePort: 31999
      name: omninginx
   selector:
      k8s-app: appname
      component: nginx
      env: dev

NgnixレプリケーションコントローラーYaml

apiVersion: v1
kind: ReplicationController
metadata:
   name: appname
spec:
   replicas: replica_count
   template:
      metadata:
         name: appname
         labels:
            k8s-app: appname
            component: nginx
               env: env_name
spec:
   nodeSelector:
      resource-group: oppv
   containers:
      - name: appname
      image: IMAGE_TEMPLATE
      imagePullPolicy: Always
      ports:
         - containerPort: 8080
         resources:
            requests:
               memory: "request_mem"
               cpu: "request_cpu"
            limits:
               memory: "limit_mem"
               cpu: "limit_cpu"
            env:
            - name: BACKEND_HOST
               value: oppv-env_name-node:3000

フロントエンドサービスYamlファイル

apiVersion: v1
kind: Service
metadata:
   name: appname
   labels:
      k8s-app: appname
spec:
   type: NodePort
   ports:
   - name: http
      port: 3000
      protocol: TCP
      targetPort: 3000
   selector:
      k8s-app: appname
      component: nodejs
      env: dev

フロントエンド複製コントローラーYamlファイル

apiVersion: v1
kind: ReplicationController
metadata:
   name: Frontend
spec:
   replicas: 3
   template:
      metadata:
         name: frontend
         labels:
            k8s-app: Frontend
            component: nodejs
            env: Dev
spec:
   nodeSelector:
      resource-group: oppv
   containers:
      - name: appname
         image: IMAGE_TEMPLATE
         imagePullPolicy: Always
         ports:
            - containerPort: 3000
            resources:
               requests:
                  memory: "request_mem"
                  cpu: "limit_cpu"
                  limits:
                  memory: "limit_mem"
                  cpu: "limit_cpu"
            env:
               - name: ENV
               valueFrom:
               configMapKeyRef:
               name: appname
               key: config-env

バックエンドサービスYamlファイル

apiVersion: v1
kind: Service
metadata:
   name: backend
   labels:
      k8s-app: backend
spec:
   type: NodePort
   ports:
   - name: http
      port: 9010
      protocol: TCP
      targetPort: 9000
   selector:
      k8s-app: appname
      component: play
      env: dev

バックアップされたレプリケーションコントローラーYamlファイル

apiVersion: v1
kind: ReplicationController
metadata:
   name: backend
spec:
   replicas: 3
   template:
      metadata:
         name: backend
      labels:
         k8s-app: beckend
         component: play
         env: dev
spec:
   nodeSelector:
      resource-group: oppv
      containers:
         - name: appname
            image: IMAGE_TEMPLATE
            imagePullPolicy: Always
            ports:
            - containerPort: 9000
            command: [ "./docker-entrypoint.sh" ]
            resources:
               requests:
                  memory: "request_mem"
                  cpu: "request_cpu"
               limits:
                  memory: "limit_mem"
                  cpu: "limit_cpu"
            volumeMounts:
               - name: config-volume
               mountPath:/app/vipin/play/conf
         volumes:
            - name: config-volume
            configMap:
            name: appname

Kubernetes-自動スケーリング

*Autoscaling* はKubernetesクラスターの主要な機能の1つです。 これは、サービス応答の需要が増加するにつれてクラスターがノードの数を増やし、要件が減少するにつれてノードの数を減らすことができる機能です。 自動スケーリングのこの機能は、現在Google Cloud Engine（GCE）およびGoogle Container Engine（GKE）でサポートされており、まもなくAWSで開始されます。

GCEでスケーラブルなインフラストラクチャをセットアップするには、まず、Googleクラウドモニタリング、Googleクラウドロギング、スタックドライバーの機能を有効にしたアクティブなGCEプロジェクトが必要です。

最初に、いくつかのノードが実行されているクラスターをセットアップします。完了したら、次の環境変数を設定する必要があります。

環境変数

export NUM_NODES = 2
export KUBE_AUTOSCALER_MIN_NODES = 2
export KUBE_AUTOSCALER_MAX_NODES = 5
export KUBE_ENABLE_CLUSTER_AUTOSCALER = true

完了したら、 kube-up.sh を実行してクラスターを起動します。これにより、クラスターの自動スカラーアドオンと一緒にクラスターが作成されます。

./cluster/kube-up.sh

クラスターの作成時に、次のkubectlコマンドを使用してクラスターを確認できます。

$ kubectl get nodes
NAME                             STATUS                       AGE
kubernetes-master                Ready,SchedulingDisabled     10m
kubernetes-minion-group-de5q     Ready                        10m
kubernetes-minion-group-yhdx     Ready                        8m

これで、クラスターにアプリケーションをデプロイし、水平ポッドオートスケーラーを有効にできます。これは、次のコマンドを使用して実行できます。

$ kubectl autoscale deployment <Application Name> --cpu-percent = 50 --min = 1 --
max = 10

上記のコマンドは、アプリケーションの負荷が増加しても、PODのレプリカを少なくとも1つ、最大10個保持することを示しています。

*$ kubclt get hpa* コマンドを実行して、オートスケーラーのステータスを確認できます。 次のコマンドを使用して、ポッドの負荷を増やします。

$ kubectl run -i --tty load-generator --image = busybox/bin/sh
$ while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done

*$ kubectl get hpa* コマンドを実行して、 *hpa* を確認できます。

$ kubectl get hpa
NAME         REFERENCE                     TARGET CURRENT
php-apache   Deployment/php-apache/scale    50%    310%

MINPODS  MAXPODS   AGE
  1        20      2m

$ kubectl get deployment php-apache
NAME         DESIRED    CURRENT    UP-TO-DATE    AVAILABLE   AGE
php-apache      7          7           7            3        4m

次のコマンドを使用して、実行中のポッドの数を確認できます。

jsz@jsz-desk2:~/k8s-src$ kubectl get pods
php-apache-2046965998-3ewo6 0/1        Pending 0         1m
php-apache-2046965998-8m03k 1/1        Running 0         1m
php-apache-2046965998-ddpgp 1/1        Running 0         5m
php-apache-2046965998-lrik6 1/1        Running 0         1m
php-apache-2046965998-nj465 0/1        Pending 0         1m
php-apache-2046965998-tmwg1 1/1        Running 0         1m
php-apache-2046965998-xkbw1 0/1        Pending 0         1m

そして最後に、ノードのステータスを取得できます。

$ kubectl get nodes
NAME                             STATUS                        AGE
kubernetes-master                Ready,SchedulingDisabled      9m
kubernetes-minion-group-6z5i     Ready                         43s
kubernetes-minion-group-de5q     Ready                         9m
kubernetes-minion-group-yhdx     Ready                         9m

Kubernetes-ダッシュボードのセットアップ

Kubernetesダッシュボードのセットアップには、セットアップの前提条件として必要な一連のツールを使用したいくつかの手順が含まれます。

Docker（1.3以降）
行く（1.5+）
nodejs（4.2.2+）
npm（1.3以降）
Java（7+）
gulp（3.9+）
Kubernetes（1.1.2以降）

ダッシュボードのセットアップ

$ sudo apt-get update && sudo apt-get upgrade

Installing Python
$ sudo apt-get install python
$ sudo apt-get install python3

Installing GCC
$ sudo apt-get install gcc-4.8 g++-4.8

Installing make
$ sudo apt-get install make

Installing Java
$ sudo apt-get install openjdk-7-jdk

Installing Node.js
$ wget https://nodejs.org/dist/v4.2.2/node-v4.2.2.tar.gz
$ tar -xzf node-v4.2.2.tar.gz
$ cd node-v4.2.2
$ ./configure
$ make
$ sudo make install

Installing gulp
$ npm install -g gulp
$ npm install gulp

バージョンの確認

Java Version
$ java –version
java version "1.7.0_91"
OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-1~deb8u1+rpi1)
OpenJDK Zero VM (build 24.91-b01, mixed mode)

$ node –v
V4.2.2

$ npn -v
2.14.7

$ gulp -v
[09:51:28] CLI version 3.9.0

$ sudo gcc --version
gcc (Raspbian 4.8.4-1) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc. This is free software;
see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

GOのインストール

$ git clone https://go.googlesource.com/go
$ cd go
$ git checkout go1.4.3
$ cd src

Building GO
$ ./all.bash
$ vi/root/.bashrc
In the .bashrc
   export GOROOT = $HOME/go
   export PATH = $PATH:$GOROOT/bin

$ go version
go version go1.4.3 linux/arm

Kubernetes Dashboardのインストール

$ git clone https://github.com/kubernetes/dashboard.git
$ cd dashboard
$ npm install -g bower

ダッシュボードを実行する

$ git clone https://github.com/kubernetes/dashboard.git
$ cd dashboard
$ npm install -g bower
$ gulp serve
[11:19:12] Requiring external module babel-core/register
[11:20:50] Using gulpfile ~/dashboard/gulpfile.babel.js
[11:20:50] Starting 'package-backend-source'...
[11:20:50] Starting 'kill-backend'...
[11:20:50] Finished 'kill-backend' after 1.39 ms
[11:20:50] Starting 'scripts'...
[11:20:53] Starting 'styles'...
[11:21:41] Finished 'scripts' after 50 s
[11:21:42] Finished 'package-backend-source' after 52 s
[11:21:42] Starting 'backend'...
[11:21:43] Finished 'styles' after 49 s
[11:21:43] Starting 'index'...
[11:21:44] Finished 'index' after 1.43 s
[11:21:44] Starting 'watch'...
[11:21:45] Finished 'watch' after 1.41 s
[11:23:27] Finished 'backend' after 1.73 min
[11:23:27] Starting 'spawn-backend'...
[11:23:27] Finished 'spawn-backend' after 88 ms
[11:23:27] Starting 'serve'...
2016/02/01 11:23:27 Starting HTTP server on port 9091
2016/02/01 11:23:27 Creating API client for
2016/02/01 11:23:27 Creating Heapster REST client for http://localhost:8082
[11:23:27] Finished 'serve' after 312 ms
[BS] [BrowserSync SPA] Running...
[BS] Access URLs:
--------------------------------------
Local: http://localhost:9090/
External: http://192.168.1.21:9090/
--------------------------------------
UI: http://localhost:3001
UI External: http://192.168.1.21:3001
--------------------------------------
[BS] Serving files from:/root/dashboard/.tmp/serve
[BS] Serving files from:/root/dashboard/src/app/frontend
[BS] Serving files from:/root/dashboard/src/app

Kubernetesダッシュボード

Kubernetes Dashboard

Kubernetes-監視

監視は、大規模なクラスターを管理するための重要なコンポーネントの1つです。このために、多くのツールがあります。

Prometheusを使用した監視

これは、監視および警告システムです。 SoundCloudで構築され、2012年にオープンソース化されました。多次元データを非常にうまく処理します。

プロメテウスには、監視に参加するための複数のコンポーネントがあります-

プロメテウス-データをスクラップして保存するコアコンポーネントです。
Prometheusノードexplore -ホストレベルのマトリックスを取得し、それらをPrometheusに公開します。
Ranch-eye - haproxy であり、 cAdvisor 統計をPrometheusに公開します。
Grafana -データの視覚化。
InfuxDB -牧場主からのデータを保存するために特に使用される時系列データベース。
Prom-ranch-exporter -これは単純なnode.jsアプリケーションであり、Rancherサーバーにサービスのスタックのステータスを照会するのに役立ちます。

Prometheusによる監視

セマテキストDockerエージェント

これは、最新のDocker対応メトリック、イベント、およびログ収集エージェントです。すべてのDockerホストで小さなコンテナーとして実行され、すべてのクラスターノードとコンテナーのログ、メトリック、およびイベントを収集します。コアサービスがDockerコンテナーに展開されている場合、Kubernetesコアサービスのコンテナーを含むすべてのコンテナー（1つのポッドに複数のコンテナーが含まれる場合があります）を検出します。展開後、すべてのログとメトリックはすぐに使用できます。

ノードへのエージェントの展開

Kubernetesは、ポッドがクラスターに追加されることを保証するDeamonSetsを提供します。

SemaText Dockerエージェントの構成

環境変数を介して構成されます。

apps.sematext.comで無料アカウントを取得します（まだお持ちでない場合）。

タイプ「Docker」のSPMアプリを作成して、SPMアプリトークンを取得します。 SPMアプリはKubernetesのパフォーマンスメトリックとイベントを保持します。

Logseneアプリを作成して、Logseneアプリトークンを取得します。 LogseneアプリはKubernetesログを保持します。

以下に示すように、DaemonSet定義のLOGSENE_TOKENおよびSPM_TOKENの値を編集します。

最新のsematext-agent-daemonset.yml（生のプレーンテキスト）テンプレートを取得します（以下も参照）。
ディスク上のどこかに保存します。
SPM_TOKENおよびLOGSENE_TOKENプレースホルダーをSPMおよびLogsene Appトークンに置き換えます。

DaemonSetオブジェクトを作成する

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
   name: sematext-agent
spec:
   template:
      metadata:
         labels:
            app: sematext-agent
      spec:
         selector: {}
         dnsPolicy: "ClusterFirst"
         restartPolicy: "Always"
         containers:
         - name: sematext-agent
            image: sematext/sematext-agent-docker:latest
            imagePullPolicy: "Always"
            env:
            - name: SPM_TOKEN
               value: "REPLACE THIS WITH YOUR SPM TOKEN"
            - name: LOGSENE_TOKEN
               value: "REPLACE THIS WITH YOUR LOGSENE TOKEN"
            - name: KUBERNETES
               value: "1"
            volumeMounts:
               - mountPath:/var/run/docker.sock
                  name: docker-sock
               - mountPath:/etc/localtime
                  name: localtime
            volumes:
               - name: docker-sock
                  hostPath:
                     path:/var/run/docker.sock
               - name: localtime
                  hostPath:
                     path:/etc/localtime

kubectlを使用してSematext Agent Dockerを実行する

$ kubectl create -f sematext-agent-daemonset.yml
daemonset "sematext-agent-daemonset" created

Kubernetesログ

Kubernetesコンテナーのログは、Dockerコンテナーのログと大差ありません。ただし、Kubernetesユーザーは、展開されたポッドのログを表示する必要があります。したがって、次のようにログ検索にKubernetes固有の情報を利用できるようにすることは非常に便利です-

Kubernetes名前空間
Kubernetesポッド名
Kubernetesコンテナー名
Dockerイメージ名
Kubernetes UID

ELKスタックとLogSpoutの使用

ELKスタックには、Elasticsearch、Logstash、およびKibanaが含まれます。ログを収集してログプラットフォームに転送するには、LogSpoutを使用します（FluentDなどの他のオプションがあります）。

次のコードは、KubernetesでELKクラスターをセットアップし、ElasticSearchのサービスを作成する方法を示しています-

apiVersion: v1
kind: Service
metadata:
   name: elasticsearch
   namespace: elk
   labels:
      component: elasticsearch
spec:
   type: LoadBalancer
   selector:
      component: elasticsearch
   ports:
   - name: http
      port: 9200
      protocol: TCP
   - name: transport
      port: 9300
      protocol: TCP

複製コントローラーの作成

apiVersion: v1
kind: ReplicationController
metadata:
   name: es
   namespace: elk
   labels:
      component: elasticsearch
spec:
   replicas: 1
   template:
      metadata:
         labels:
            component: elasticsearch
spec:
serviceAccount: elasticsearch
containers:
   - name: es
      securityContext:
      capabilities:
      add:
      - IPC_LOCK
   image: quay.io/pires/docker-elasticsearch-kubernetes:1.7.1-4
   env:
   - name: KUBERNETES_CA_CERTIFICATE_FILE
   value:/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
   - name: NAMESPACE
   valueFrom:
      fieldRef:
         fieldPath: metadata.namespace
   - name: "CLUSTER_NAME"
      value: "myesdb"
   - name: "DISCOVERY_SERVICE"
      value: "elasticsearch"
   - name: NODE_MASTER
      value: "true"
   - name: NODE_DATA
      value: "true"
   - name: HTTP_ENABLE
      value: "true"
ports:
- containerPort: 9200
   name: http
   protocol: TCP
- containerPort: 9300
volumeMounts:
- mountPath:/data
   name: storage
volumes:
   - name: storage
      emptyDir: {}

木花URL

Kibanaの場合、Elasticsearch URLを環境変数として提供します。

- name: KIBANA_ES_URL
value: "http://elasticsearch.elk.svc.cluster.local:9200"
- name: KUBERNETES_TRUST_CERT
value: "true"

Kibana UIは、コンテナポート5601および対応するホスト/ノードポートの組み合わせで到達可能です。開始時には、Kibanaにはデータがありません（データをプッシュしていないため、これは予想されます）。

Kubernetes-quick-guide

Kubernetes-概要

Kubernetesの機能

Kubernetes-アーキテクチャ

Kubernetes-クラスターアーキテクチャ

Kubernetes-マスターマシンコンポーネント

etcd

APIサーバー

コントローラーマネージャー

スケジューラー

Kubernetes-ノードコンポーネント

港湾労働者

キューブレットサービス

Kubernetesプロキシサービス

Kubernetes-マスターおよびノー​​ド構造

Kubernetes-セットアップ

前提条件

Docker Engineをインストールする

etcd 2.0をインストールする

kube-apiserverを構成する

kube Controller Managerを構成する

Kubernetesノードの構成

Kubernetes-画像

Kubernetes-ジョブ

ジョブを作成する

スケジュールされたジョブ

Kubernetes-ラベルとセレクター

ラベル

セレクター

等式ベースのセレクター

セットベースのセレクター

Kubernetes-名前空間

名前空間の機能

名前空間を作成する

名前空間を制御する

サービスでのネームスペースの使用-例

Kubernetes-ノード

セレクターを使用したサービス

ノードコントローラー

Kubernetes-サービス

セレクタなしのサービス

セレクターを使用したサービス構成ファイル

マルチポートサービスの作成

サービスの種類

Kubernetes-ポッド

ポッドの種類

シングルコンテナポッド

マルチコンテナポッド

Kubernetes-レプリケーションコントローラー

セットアップの詳細

Kubernetes-レプリカセット

セットアップの詳細

Kubernetes-展開

展開の変更

展開戦略

配置を作成

展開を取得する

展開のステータスを確認する

展開の更新

前の展開へのロールバック

Kubernetes-ボリューム

Kubernetesボリュームの種類

永続ボリュームと永続ボリューム要求

永続ボリュームの作成

PVの作成

PVの確認

PVの説明

永続的なボリューム要求の作成

PVCの作成

PVCに関する詳細の取得

PVCの説明

PODでPVおよびPVCを使用する

Kubernetes-秘密

テキストファイルから作成

Yamlファイルから作成する

シークレットを作成する

シークレットを使用する

環境変数として

ボリュームとして

環境変数としての秘密の構成

Kubernetes-マスターおよびノード構造