👨🏽‍🔧 👰🏽 ☝🏽 Kubernetesの基本 ↗️ 👨🏽‍⚕️ 👓

この出版物では、興味深いが、Kubernetesコンテナ管理システムであるHabrについてはあまり説明されていませんでした。

Kubernetesとは何ですか？

Kubernetesは、Linuxコンテナクラスタを単一システムとして管理するために設計されたオープンソースプロジェクトです。 Kubernetesは、多数のホストでDockerコンテナを管理および実行し、多数のコンテナを共同ホストおよび複製します。このプロジェクトはGoogleによって開始され、現在はMicrosoft、RedHat、IBM、Dockerなどの多くの企業によってサポートされています。

Googleは10年以上にわたってコンテナテクノロジーを使用してきました。彼女は、1週間で20億個以上のコンテナを発売することから始めました。 Kubernetesプロジェクトの助けを借りて、同社はスケーラブルなコンテナの起動用に設計されたオープンプラットフォームを作成した経験を共有しています。

プロジェクトには2つの目標があります。 Dockerコンテナーを使用する場合、多数のDockerホストでコンテナーをすぐにスケーリングおよび実行する方法、およびそれらのバランスをとる方法について次の質問が発生します。このプロジェクトでは、コンテナの論理グループを定義する高レベルAPIを提案しています。これにより、コンテナプールの定義、負荷の分散、および場所の指定が可能になります。

Kubernetesの概念

ノード （ node.md ）：ノードはKubernetesクラスター内のマシンです。

ポッド （ pods.md ）：ポッドは、ユニットとして実行される共有パーティションを持つコンテナのグループです。

レプリケーションコントローラー （ replication-controller.md ）：レプリケーションコントローラーは、特定の数の「レプリカ」ポッドが常に起動されるようにします。

サービス （ services.md ）：Kubernetesのサービスは、ポッドの論理的な統合セットとそれらのアクセスポリシーを定義する抽象化です。

ボリューム （ volumes.md ）：ボリューム（セクション）はディレクトリであり、コンテナ内で使用可能なデータが含まれている場合があります。

ラベル （ labels.md ）：ラベルは、ポッドなどのオブジェクトに添付されるキー/値のペアです。ラベルを使用して、オブジェクトのセットを作成および選択できます。

Kubectlコマンドラインインターフェイス （ kubectl.md ）：Kubernetesを管理するためのkubectlコマンドラインインターフェイス。

Kubernetesのアーキテクチャ

稼働中のKubernetesクラスターには、ノード（kubelet）およびウィザードコンポーネント（API、スケジューラーなど）で実行されているエージェントが、分散ストレージソリューションの上に含まれています。上記の図は、最終的には望ましい状態を示していますが、まだいくつかの作業が行われていますが、たとえば、kubelet（実際にはすべてのコンポーネント）をコンテナー内で独立して実行し、スケジューラーを100％接続可能にする方法です。

野田クベルネテス

システムアーキテクチャを見ると、各ノードで動作するサービスとクラスター管理レベルのサービスに分類できます。各Kubernetesノードで、ウィザードからノードを管理し、アプリケーションを起動するために必要なサービスが起動されます。もちろん、Dockerは各ノードで起動されます。 Dockerは、イメージのロードとコンテナーの起動を提供します。

クベレット

Kubeletは、コンテナ、イメージ、パーティションなどによってポッドを管理します。

キューブプロキシ

また、単純なプロキシバランサーが各ノードで起動されます。このサービスは各ノードで実行され、Kubernetes APIで構成されます。 Kube-Proxyは、一連のバックエンド間でTCPおよびUDPストリームの最も単純なリダイレクト（ラウンドロビン）を実行できます。

Kubernetes管理コンポーネント

Kubernetes管理システムは、いくつかのコンポーネントに分かれています。現時点では、それらはすべてマスターノードで実行されていますが、すぐにフェールオーバークラスターを作成できるように変更されます。これらのコンポーネントは連動して、クラスターの単一のビューを提供します。

etcd

ウィザードの状態はetcdのインスタンスに保存されます。これにより、構成データの信頼性の高い保存と、状態変更に関する他のコンポーネントへのタイムリーな通知が保証されます。

Kubernetes APIサーバー

Kubernetes APIはAPIサーバーを提供します。これは、個別のコンポーネントまたはプラグインに実装された組み込みのビジネスロジックを備えたCRUDサーバーを対象としています。主にREST操作を処理し、チェックしてetcdの対応するオブジェクト（および他のリポジトリのイベント）を更新します。

スケジューラー

スケジューラーは、/ binding API呼び出しを介して、非実行ポッドをノードにバインドします。スケジューラー接続。複数のスケジューラとカスタムスケジューラのサポートが計画されています。

Kubernetes Controller Managerサーバー

他のすべてのクラスターレベルの機能は、コントローラーマネージャーで提供されます。たとえば、ノードはノードコントローラによって検出、管理、および制御されます。このエンティティを最終的に個別のコンポーネントに分割して、それらを独立して接続することができます。

ReplicationControllerは、ポッドベースのAPIエンジンです。最終的には、実装時に共通のプラグインメカニズムに転送する予定です。

クラスターのセットアップ例

Ubuntu-server 14.10は、構成例のプラットフォームとして最も単純な例として選択され、同時にクラスターの基本設定を示すことができました。

テストクラスタを作成するには、ノードを作成するための3台のマシンとリモートインストール用の別のマシンを使用します。別のマシンを選択して、いずれかのノードからインストールすることはできません。

使用済みマシンのリスト：

Conf
Node1：192.168.0.10-マスター、ミニオン
Node2：192.168.0.11-ミニオン
Node3：192.168.0.12-ミニオン

ノードの準備

起動の要件：

Dockerバージョン1.2+およびbridge-utilsはすべてのノードにインストールされます
すべてのマシンが相互に接続されているため、インターネットにアクセスする必要はありません（この場合、ローカルのdockerレジストリを使用する必要があります）
ログイン/パスワードを入力せずに、sshキーを使用してすべてのノードを入力できます

ノードへのソフトウェアのインストール

公式ソースの記事に従って、Dockerをインストールできます。

node% sudo apt-get update $ sudo apt-get install wget node% wget -qO- https://get.docker.com/ | sh

インストール後のDockerの追加構成は必要ありません。 Kubernetesインストールスクリプトによって生成されます。

bridge-utilsをインストールします。

 node% sudo apt-get install bridge-utils

SSHキーを追加する

インストールスクリプトが起動されるマシンで実行します。

キーがまだ作成されていない場合は、作成します。

 conf% ssh-keygen

必要なユーザー（この場合はコア）がいることを確認した後、キーをリモートマシンにコピーします。

 conf% ssh-copy-id core@192.168.0.10 conf% ssh-copy-id core@192.168.0.11 conf% ssh-copy-id core@192.168.0.12

Kubernetesをインストールする

次に、Kubernetesを直接インストールします。これを行うには、まず、GitHubから利用可能な最新リリースをダウンロードして解凍します。

 conf% wget https://github.com/GoogleCloudPlatform/kubernetes/releases/download/v0.17.0/kubernetes.tar.gz conf% tar xzf ./kubernetes.tar.gz conf% cd ./kubernetes

カスタマイズ

Kubernetesは、インストールが構成ファイルを介して実行される前に、標準のサンプルスクリプトを介して完全に構成されます。インストール中に、。/ cluster / ubuntu /フォルダー内のスクリプトを使用します。

まず、インストールに必要なKubernetes、etcd、およびflannelバイナリをダウンロードおよび準備するスクリプト./cluster/ubuntu/build.shを変更します。

 conf% vim ./cluster/ubuntu/build.sh

後者を使用するには、執筆時点でリリース0.17.0を置き換える必要があります。

 # k8s echo "Download kubernetes release ..." K8S_VERSION="v0.15.0"

オン：

 # k8s echo "Download kubernetes release ..." K8S_VERSION="v0.17.0"

そして実行：

 conf% cd ./cluster/ubuntu/ conf% ./build.sh #       ,   .

次に、ファイル./config-default.shを編集する将来のクラスターのパラメーターを示します。

 ## Contains configuration values for the Ubuntu cluster #         , MASTER-   #     <user_1@ip_1> <user_2@ip_2> <user_3@ip_3>  -  #            ssh- export nodes="core@192.168.0.10 core@192.168.0.10 core@192.168.0.10" #    : a(master)  i(minion)  ai(master  minion),     ,      . export roles=("ai" "i" "i") #    export NUM_MINIONS=${NUM_MINIONS:-3} #  IP-  ,       . #    ,      , ..         . #  IP-    iptables  . export PORTAL_NET=192.168.3.0/24 #           flannel. #flannel       24   ,        Docker-. #     PORTAL_NET export FLANNEL_NET=172.16.0.0/16 # Admission Controllers      . ADMISSION_CONTROL=NamespaceLifecycle,NamespaceAutoProvision,LimitRanger,ResourceQuota #    Docker.       #   --insecure-registry   . DOCKER_OPTS=""

これでセットアップが完了し、インストールに進むことができます。

設置

まず、システムにssh-agentを伝え、sshキーを使用してこれを行う必要があります。

 eval `ssh-agent -s` ssh-add ///

次に、インストールに直接移動します。これを行うには、スクリプト./kubernetes/cluster/kube-up.shを使用します。このスクリプトは、ubuntuを使用するように指定する必要があります。

 conf% cd ../ conf% KUBERNETES_PROVIDER=ubuntu ./kube-up.sh

インストール中に、スクリプトは各ノードのsudoパスワードを要求します。インストールの最後に、クラスターのステータスを確認し、ノードとKubernetes APIアドレスのリストを表示します。

スクリプト出力の例

 Starting cluster using provider: ubuntu ... calling verify-prereqs ... calling kube-up Deploying master and minion on machine 192.168.0.10 <  > [sudo] password to copy files and start node: etcd start/running, process 16384 Connection to 192.168.0.10 closed. Deploying minion on machine 192.168.0.11 <  > [sudo] password to copy files and start minion: etcd start/running, process 12325 Connection to 192.168.0.11 closed. Deploying minion on machine 192.168.0.12 <  > [sudo] password to copy files and start minion: etcd start/running, process 10217 Connection to 192.168.0.12 closed. Validating master Validating core@192.168.0.10 Validating core@192.168.0.11 Validating core@192.168.0.12 Kubernetes cluster is running. The master is running at: http://192.168.0.10 ... calling validate-cluster Found 3 nodes. 1 NAME LABELS STATUS 2 192.168.0.10 <none> Ready 3 192.168.0.11 <none> Ready 4 192.168.0.12 <none> Ready Validate output: NAME STATUS MESSAGE ERROR etcd-0 Healthy {"action":"get","node":{"dir":true,"nodes":[{"key":"/coreos.com","dir":true,"modifiedIndex":11,"createdIndex":11},{"key":"/registry","dir":true,"modifiedIndex":5,"createdIndex":5}],"modifiedIndex":5,"createdIndex":5}} nil controller-manager Healthy ok nil scheduler Healthy ok nil Cluster validation succeeded Done, listing cluster services: Kubernetes master is running at http://192.168.0.10:8080

新しいクラスターに存在するノードとサービスを見てみましょう。

 conf% cp ../kubernetes/platforms/linux/amd64/kubectl /opt/bin/ conf% /opt/bin/kubectl get services,minions -s "http://192.168.0.10:8080" NAME LABELS SELECTOR IP PORT(S) kubernetes component=apiserver,provider=kubernetes <none> 192.168.3.2 443/TCP kubernetes-ro component=apiserver,provider=kubernetes <none> 192.168.3.1 80/TCP NAME LABELS STATUS 192.168.0.10 <none> Ready 192.168.0.11 <none> Ready 192.168.0.12 <none> Ready

準備完了状態のインストール済みノードのリストと、2つの事前インストール済みサービスkubernetesおよびkubernetes-roが表示されます。これはKubernetes APIに直接アクセスするためのプロキシです。 Kubernetesサービスと同様に、kubernetesとkubernetes-roは、どのノードからでもIPアドレスで直接アクセスできます。

テストサービスの開始

サービスを開始するには、ドッカーコンテナを準備し、それに基づいてサービスを作成する必要があります。複雑にならないように、この例ではパブリックnginxコンテナーを使用します。サービスの必須コンポーネントはレプリケーションコントローラーです。これにより、必要なコンテナー（またはポッド）のセットが起動され、サービスがどのIPアドレスとポートを決定するか、サービスがポッド間でリッスンするルールを決定します。

任意のサービスは、2つの方法で起動できます。手動と構成ファイルの使用です。両方を検討してください。

手動サービス開始

レプリケーションコントローラーを作成することから始めましょう。

 conf% /opt/bin/kubectl run-container nginx --port=80 --port=443 --image=nginx --replicas=6 -s "http://192.168.0.10:8080"

どこで：

nginxは、将来のrcの名前です
--port-rcコンテナーがリッスンするポート
--image-コンテナーの起動元のイメージ
--replicas = 6-レプリカの数

私たちが得たものを見てみましょう：

 /opt/bin/kubectl get pods,rc -s "http://192.168.0.10:8080"

おわりに

 POD IP CONTAINER(S) IMAGE(S) HOST LABELS STATUS CREATED MESSAGE nginx-3gii4 172.16.58.4 192.168.0.11/192.168.0.11 run-container=nginx Running 9 seconds nginx nginx Running 9 seconds nginx-3xudc 172.16.62.6 192.168.0.10/192.168.0.10 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds nginx-igpon 172.16.58.6 192.168.0.11/192.168.0.11 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds nginx-km78j 172.16.58.5 192.168.0.11/192.168.0.11 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds nginx-sjb39 172.16.83.4 192.168.0.12/192.168.0.12 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds nginx-zk1wv 172.16.62.7 192.168.0.10/192.168.0.10 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS nginx nginx nginx run-container=nginx 6

レプリケーションコントローラーはnginxという名前で作成され、レプリカの数は6です。レプリカはノード上でランダムに実行され、各ポッドの場所はHOST列に示されます。

結論は、いくつかの場合に与えられたものとは異なる場合があります。例えば：

ポッドの一部は保留状態です。これは、ポッドがまだ開始されていないことを意味します。少し待つ必要があります
ポッドにはHOSTが定義されていません。これは、ポッドが起動されるノードがスケジューラーによってまだ割り当てられていないことを意味します

次に、レプリケーションコントローラーをバックエンドとして使用するサービスを作成します。

httpの場合：

 conf% /opt/bin/kubectl expose rc nginx --port=80 --target-port=80 --service-name=nginx-http -s "http://192.168.0.10:8080"

httpsの場合：

 conf% /opt/bin/kubectl expose rc nginx --port=443 --target-port=443 --service-name=nginx-https -s "http://192.168.0.10:8080"

どこで：

rc nginx-使用されるリソースのタイプと名前（rc = Replication Controller）
--port-サービスが「リッスン」するポート
--target-port-リクエストがブロードキャストされるコンテナのポート
--service-name-将来のサービス名

結果を確認します。

 /opt/bin/kubectl get rc,services -s "http://192.168.0.10:8080"

おわりに

 CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS nginx nginx nginx run-container=nginx 6 NAME LABELS SELECTOR IP PORT(S) kubernetes component=apiserver,provider=kubernetes <none> 192.168.3.2 443/TCP kubernetes-ro component=apiserver,provider=kubernetes <none> 192.168.3.1 80/TCP nginx-http <none> run-container=nginx 192.168.3.66 80/TCP nginx-https <none> run-container=nginx 192.168.3.172 443/TCP

無視を確認するには、任意のノードに移動してコンソールで実行します。

 node% curl http://192.168.3.66

curl出力では、標準のnginxウェルカムページが表示されます。完了、サービスは稼働中です。

構成を使用してサービスを開始する

この起動方法では、レプリケーションコントローラーとサービスの構成を作成する必要があります。 Kubernetesは、yamlおよびjson形式の設定を受け入れます。 Yamlは私に近いため、使用します。

まず、以前の実験からクラスターをクリーンアップします。

 conf% /opt/bin/kubectl delete services nginx-http nginx-https -s "http://192.168.0.10:8080" conf% /opt/bin/kubectl stop rc nginx -s "http://192.168.0.10:8080"     .

nginx_rc.yaml

内容

 apiVersion: v1beta3 kind: ReplicationController #   ReplicationController metadata: name: nginx-controller spec: #    replicas: 6 selector: name: nginx template: metadata: labels: name: nginx spec: containers: #  - name: nginx image: nginx #  ports: - containerPort: 80 - containerPort: 443 livenessProbe: #    enabled: true type: http #     pod'     initialDelaySeconds: 30 TimeoutSeconds: 5 # http  httpGet: path: / port: 80 portals: - destination: nginx

構成を適用します。

 conf% /opt/bin/kubectl create -f ./nginx_rc.yaml -s "http://192.168.0.10:8080"

結果を確認します。

 conf% /opt/bin/kubectl get pods,rc -s "http://192.168.0.10:8080"

おわりに

 POD IP CONTAINER(S) IMAGE(S) HOST LABELS STATUS CREATED MESSAGE nginx-controller-0wklg 172.16.58.7 192.168.0.11/192.168.0.11 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-2jynt 172.16.58.8 192.168.0.11/192.168.0.11 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-8ra6j 172.16.62.8 192.168.0.10/192.168.0.10 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-avmu8 172.16.58.9 192.168.0.11/192.168.0.11 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-ddr4y 172.16.83.7 192.168.0.12/192.168.0.12 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-qb2wb 172.16.83.5 192.168.0.12/192.168.0.12 name=nginx Running About a minute nginx nginx Running About a minute CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS nginx-controller nginx nginx name=nginx 6

レプリケーションコントローラーはnginxという名前で作成され、レプリカの数は6です。レプリカはノード上でランダムに実行され、各ポッドの場所はHOST列に示されます。

nginx_service.yaml

内容

 apiVersion: v1beta3 kind: Service metadata: name: nginx spec: publicIPs: - 12.0.0.5 # IP       . ports: - name: http port: 80 #      targetPort: 80         protocol: TCP - name: https port: 443 targetPort: 443 protocol: TCP selector: name: nginx #        ReplicationController

configを使用すると、複数のポートを1つのサービスに割り当てることができることに気付くかもしれません。

構成を適用します。

 conf% /opt/bin/kubectl create -f ./nginx_service.yaml -s "http://192.168.0.10:8080"

結果を確認します。

 /opt/bin/kubectl get rc,services -s "http://192.168.0.10:8080"

おわりに

 CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS nginx-controller nginx nginx name=nginx 6 NAME LABELS SELECTOR IP PORT(S) kubernetes component=apiserver,provider=kubernetes <none> 192.168.3.2 443/TCP kubernetes-ro component=apiserver,provider=kubernetes <none> 192.168.3.1 80/TCP nginx <none> name=nginx 192.168.3.214 80/TCP 12.0.0.5 443/TCP

無視を確認するには、任意のノードに移動してコンソールで実行します。

 node% curl http://192.168.3.214 node% curl http://12.0.0.5

curl出力では、標準のnginxウェルカムページが表示されます。

マージンノート

結論として、システムを設計するときにつまずかなければならなかったいくつかの重要なポイントを説明したいと思います。それらは、異なる要素のセットをサービスに変えることができるモジュールであるkube-proxyの作業と接続されていました。

PORTAL_NET。 本質自体が興味深いので、これがどのように実装されているかを知ることを提案します。

短い掘り下げから、シンプルだが効果的なモデルの実現に至りました。iptables-saveの出力を見てください。

 -A PREROUTING -j KUBE-PORTALS-CONTAINER -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER -A OUTPUT -j KUBE-PORTALS-HOST -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER -A POSTROUTING -s 10.0.42.0/24 ! -o docker0 -j MASQUERADE -A KUBE-PORTALS-CONTAINER -d 10.0.0.2/32 -p tcp -m comment --comment "default/kubernetes:" -m tcp --dport 443 -j REDIRECT --to-ports 46041 -A KUBE-PORTALS-CONTAINER -d 10.0.0.1/32 -p tcp -m comment --comment "default/kubernetes-ro:" -m tcp --dport 80 -j REDIRECT --to-ports 58340 -A KUBE-PORTALS-HOST -d 10.0.0.2/32 -p tcp -m comment --comment "default/kubernetes:" -m tcp --dport 443 -j DNAT --to-destination 172.16.67.69:46041 -A KUBE-PORTALS-HOST -d 10.0.0.1/32 -p tcp -m comment --comment "default/kubernetes-ro:" -m tcp --dport 80 -j DNAT --to-destination 172.16.67.69:58340

iptablesに入ったサービスのIPアドレスへのすべての要求は、kube-proxyがリッスンするポートでラップされます。これに関して、1つの問題が発生します。Kubernetes自体は、ユーザーとの通信の問題を解決しません。したがって、次のような外部手段でこの問題を解決する必要があります。

gcloud-Googleからの有料開発
bgp-サブネットアナウンスメントの使用
IPVS
その他のオプションは多数あります

ソースIP同じ。 nginxサービスを設定するとき、興味深い問題に直面しなければなりませんでした。マニュアルの行のように見えました：「kube-proxyを使用すると、サービスにアクセスするパケットのソースIPがわかりにくくなります」。文字通り、kube-proxyを使用する場合、パッケージのソースアドレスを非表示にします。つまり、source-IPに基づいて構築されたすべての処理は、kube-proxyを使用する前に実行する必要があります。

ご覧いただきありがとうございます。

残念ながら、伝えたいすべての情報を1つの記事に収めることはできません。

Kubernetesの基本

Kubernetesとは何ですか？

Kubernetesの概念

Kubernetesのアーキテクチャ

野田クベルネテス

クベレット

キューブプロキシ

Kubernetes管理コンポーネント

etcd

Kubernetes APIサーバー

スケジューラー

Kubernetes Controller Managerサーバー

クラスターのセットアップ例

ノードの準備

起動の要件：

ノードへのソフトウェアのインストール

SSHキーを追加する

Kubernetesをインストールする

カスタマイズ

設置

テストサービスの開始

手動サービス開始

構成を使用してサービスを開始する

マージンノート

材料の使用：

More articles: