My PR was merged to mongoDB. [SERVER-32809] Fix typo in config_server_test_fixture.cpp - MongoDB
minikube start 時に [Error starting host: Error getting state for host: machine does not exist] が出た時の対処法
前提
- macOS 10.11.6
- kubectl v1.9.3
- minikube v0.25.0
発生内容
ローカル環境でminikubeにより一度作った vmを削除後、 minikube start --vm-driver=virtualbox を実行すると以下のエラーがでる
[Error starting host: Error getting state for host: machine does not exist]
起動時にvmのホスト情報が取れていなくてエラーになる minikube/start.go at master · kubernetes/minikube · GitHub
さらに内部をみると vm driverのapiで、ドライバーの状態が取れなくてエラーになっている minikube/cluster.go at master · kubernetes/minikube · GitHub
virtualboxで起動されていたvmを削除したが、minikube内部で削除された状態が残っているものと思われる
解決策
minikube delete してローカルのkubernetes clusterを削除した上で,minikube startしなおすと再度minikube vmを立ち上げれるようになる
Docker Swarm まとめ
概要
前記事(http://kakts-tec.hatenablog.com/entry/2018/02/12/220716)に引き続き, Docker公式ドキュメントのPart4 Swarmsの内容を整理します.
Part4 Swarms
Introduction
Part3ではPart2で作成したアプリケーションを取り上げ,Serviceを用いてproduction環境の定義を行い,プロセスのスケールアップも行いました.
Part4では,アプリケーションをクラスタ上にデプロイし,複数マシン上で実行させます.
マルチコンテナ,マルチマシンアプリケーションは複数のマシンをswarmと呼ばれるDockernizedされたクラスタにジョインすることで可能となります.
Understanding Swarm clusters
swarm はDockerを実行し,クラスタに参加するマシンのグループのことです.
クラスタにジョインしたあと,今までどおりdockerコマンドを使いますが,swarm manager によってクラスタ上で実行されます.
swarm内のマシンは物理マシンや仮想マシンです. swarmにジョイン後,それらのマシンはnodesと呼ばれます.
swarm manager はコンテナを実行するために複数のストラテジーを利用可能で,たとえば emptiest node と呼ばれるコンテナが一番起動されていないマシンを選んで起動する方式などがあります.
そしてglobal と呼ばれるストラテジーは, 各マシンが特定のコンテナを1つのみ持つことを保証するものです.
ユーザはcomposeファイル内でどのストラテジーを使うか定義できます.
swarm managerはswarm内でユーザのコマンドを実行できる唯一のマシンで, 他のマシンがworker としてswarmにジョインするのを認証します.
workerはキャパシティーを担保するもので, 他のマシンとやりとりする権限をもちません.
今までの章では,dockerをローカルマシン上でシングルホストモードで使用していました.
しかしDockerはswarmを使用できるswarmモードにも切り替えることができます.
swarmモードを有効にするということは,現在使用しているマシンをswarm managerにするということです.
モードの変更後, Dockerは現在使っているマシンのみというよりも,ユーザが管理するswarmクラスタ上でコマンドが実行されます.
Set up your swarm
swarmは複数のnodeで構成され,各nodeは物理マシンでも仮想マシンでも可能です. 基本的なコンセプトはシンプルで, docker swarm init を実行しswarm modeを有効にし,現在使っているマシンをswarm managerにした上で, 他のホスト上でdocker swarm join を実行させ,workerとしてswarmにジョインさせます.
Create a cluster
まず,クラスターを作成する前に,複数のVMマシンを立ち上げます.
Virtualbox環境を用意した上で話しをすすめます.
まず,docker-machineコマンドを使ってマシンを作ります.
docker-machine create --driver virtualbox node01 docker-machine create --driver virtualbox node02
LIST THE VMS AND GET THEIR IP ADDRESSES
実行後 docker-machine ls で作成したマシンの状態を確認できます.
$ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS node01 - virtualbox Running tcp://192.168.99.100:2376 v18.02.0-ce node02 - virtualbox Running tcp://192.168.99.101:2376 v18.02.0-ce
INITIALIZE THE SWARM AND ADD NODES
最初のマシンはmanagerとして稼働し,管理用コマンドを実行したり,swarmにジョインしたworkerの管理を行います.
2台目のマシンはworkerとなります.
docker-machine ssh コマンドでマシン名を指定するとVMに対してコマンドを実行できます.
ここではnode01に対してdocker swarm initを実行し,swarm managerにします.
$ docker-machine ssh node01 "docker swarm init --advertise-addr 192.168.99.100"
Swarm initialized: current node (q9gndi1k8qfwtbusob9jmav2j) is now a manager.
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-4ow9k02pfkb84fyd3jdwke0r0p0qigiac7rutprt3thn5jzrgj-590v3ftz0e5225ibrn7klensx 192.168.99.100:2377
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
注意点
Port2377と2376について
常にdocker swarm init と docker swarm joinは2377ポートに対して行います. docker-machine ls で表示される2366ポートはDockerのdaemonポートです. このポートに対して操作を行うとエラーになります.
先程のnode01に対するdocker swarm initを実行したときに,以下の文言が表示されました.
ここに書いてあるとおり, node01はswarm managerになったので,swarmに対してジョインさせたいときはdocker swarm joinを実行すると可能になります.
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-4ow9k02pfkb84fyd3jdwke0r0p0qigiac7rutprt3thn5jzrgj-590v3ftz0e5225ibrn7klensx 192.168.99.100:2377
今回はnode02をworkerにしたいのでnode02に対して実行させます.
$ docker-machine ssh node02 "docker swarm join --token SWMTKN-1-4ow9k02pfkb84fyd3jdwke0r0p0qigiac7rutprt3thn5jzrgj-590v3ftz0e5225ibrn7klensx 192.168.99.100:2377" This node joined a swarm as a worker
これでnode02をworkerに追加できました. node01上で確認するとnode01がswarm leaderになっているのがわかります.
$ docker-machine ssh node01 "docker node ls" ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS q9gndi1k8qfwtbusob9jmav2j * node01 Ready Active Leader s31768g3n99fev0sabf2i0q0g node02 Ready Active
Deploy your app on the swarm cluster
一通りswarmに対する操作は終わりあとはPart3とほぼ同じ操作を行うのみです.
前述しましたが,注意点として, swarm managerであるnode01のみがdockerコマンドを実行でき,残りのworkerでは実行できません.
Configure a docker-machine shell to the swarm manager
今まで, Dockerコマンドを実行するのにdocker-machine ssh を使ってVMとやり取りしていました. 別のやり方として,docker-machine env
このやり方は非常に便利で,なぜならローカル環境のdocker-compose.ymlを使うことができ,マシンに直接コピーせずともリモートでアプリケーションをデプロイできるからです.
さっそくdocker-machine env node01 を実行して見ます. これにより,node01に対する設定項目が出力されます.
$ docker-machine env node01 export DOCKER_TLS_VERIFY="1" export DOCKER_HOST="tcp://192.168.99.100:2376" export DOCKER_CERT_PATH="/Users/username/.docker/machine/machines/node01" export DOCKER_MACHINE_NAME="node01" # Run this command to configure your shell: # eval $(docker-machine env node01)
出力結果に書いてあるとおりに実行すると設定が完了します.
eval $(docker-machine env node01)
docker-machine ls コマンドを実行することで,現在のシェルがどのノードに対してアクティブになっているのかを確認できます.
$ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS node01 * virtualbox Running tcp://192.168.99.100:2376 v18.02.0-ce node02 - virtualbox Running tcp://192.168.99.101:2376 v18.02.0-ce
Deploy the app on the swarm manager
ここでnode01のマシンをswarm managerとして使うことができ,Part3で使ったdocker stack deploy コマンドとdocker-compose.yml でアプリケーションをデプロイできる状態になりました.
このコマンドは実行完了までに数秒かかり,デプロイしたものが利用可能になるまで時間がかかります.
docker service ps <service_name> をswarm managerで実行して全てのサービスがデプロイされていることを確認できます.
$ docker service ps getstartedlab_web ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS r07ynn2v8bj7 getstartedlab_web.1 username/get-started:part2 node02 Running Running less than a second ago m3lg9lbr23xb getstartedlab_web.2 username/get-started:part2 node01 Running Running 1 second ago pt6ajvyvkbgv getstartedlab_web.3 username/get-started:part2 node02 Running Running less than a second ago aftz97jyv5cq getstartedlab_web.4 username/get-started:part2 node01 Running Running 1 second ago k3vhukabiv5v getstartedlab_web.5 username/get-started:part2 node02 Running Running less than a second ago vzr3ujd6hjif getstartedlab_web.6 username/get-started:part2 node01 Running Running 1 second ago neeh3npk9n7g getstartedlab_web.7 username/get-started:part2 node02 Running Running less than a second ago
これによりservicesのコンテナがnode01とnode02のそれぞれにデプロイされたことがわかります.
Accessing your cluster
これでnode01とnode02のIPアドレスからアプリケーションにアクセスできるようになりました.
作成したネットワークは2つのnodeとロードバランサーに共有されています. docker-machine ls でどちらかのnodeのipへアクセスしてリロードしてみてください.
今回は7つのレプリカを指定したのでアクセスするたびに7つのコンテナにランダムに振り分けられます.
node01とnode02のどちらに対してアクセスしても適切にロードバランシングされます.
これは,swarm内の各nodeがrouting meshに参加しているためです.
これはswarm内の特定のポートに対してデプロイされたserviceが,コンテナがどのようなnode上で動いていても常にポートを持つことを保証するためです.
Docker Servicesまとめ
概要
前記事
Docker containerまとめ - kakts-log
に引き続き Docker公式ドキュメントのPart3 Servicesの内容を整理します.
Part3 Services
Introduction
パート3では、アプリケーションのスケールを行い,ロードバランシングを有効にさせます.
これを行うために,アプリケーションのヒエラルキーの一段上のレベル,Serviceについて取り上げます.
- Stack
- Services
- Container
About services
分散化されたアプリケーションにおいて,分散化された各ピースのことを"Services"と呼びます.
たとえば,もし動画のシェアリングサイトを考えたときに,おそらくアプリケーションはデータベースにアプリケーションを保存するServiceを含むのと,ユーザがアップロードしたあとにバックグラウンドで動画をトランスコードするServiceや,フロントエンドのServiceが考えられます.
Servicesは実際にはただの本番環境でのコンテナ群として扱われます.
単一のServiceは,1つのイメージを実行しますが,イメージをどのように実行するかを明文化します.
たとえば,どのポートを使うか,Serviceがキャパシティを担保するためにいくつのコンテナレプリカを実行するかなどです.
Serviceのスケーリングを行う場合は,コンテナの数を変更し,そのServiceに対して使うリソースを増やします.
Your first docker-compose.yml file
docker-compose.yml ファイルはYAML形式のファイルで,Dockerコンテナがプロダクション環境でどのように振る舞うかを定義します.
docker-compose.yml
docker-compose.yml というファイルを作成して,使っているディレクトリの直下に保存します.
version: "3"
services:
web:
# replace username/repo:tag with your name and image details
image: username/repo:tag
deploy:
replicas: 5
resources:
limits:
cpus: "0.1"
memory: 50M
restart_policy:
condition: on-failure
ports:
- "80:80"
networks:
- webnet
networks:
webnet:
内容は上記になります.具体的には以下の内容でコンテナを起動するように指定しています.
- Part2で使ったイメージをpullしてくる
- webというService名で,5つのコンテナインスタンスを起動する. 各コンテナは最大でも10%のCPUリソースと50MBのRAMを使用します.
- もしコンテナが落ちた場合すぐに再起動させる.
- ホストマシンの80番ポートをwebのポート80に対応させる.
- webのコンテナに対して,webnetと呼ばれるロードバランシングネットワークを介して80番ポートを共有させる. (内部的には,各コンテナは80番のエフェメラルポートとしてパブリッシュする)
- webnetネットワークを初期設定で定義する.
Run your new load-balanced app
docker stack deploy コマンドを実行する前に,下記コマンドを実行します.
docker swarm init
詳細はPart4で解説します.
ここでdocker stack deployコマンドを実行します .
docker stack deploy -c docker-compose.yml getstartedlab
これにより,docker-compose.yml で指定した内容をもとにServiceが起動します.
docker service ls で,立ち上げたServiceの一覧を確認できます.
$ docker service ls ID NAME MODE REPLICAS IMAGE PORTS iji3jgsi3i80 getstartedlab_web replicated 5/5 username/get-started:part2 *:80->80/tcp
NAME項目をみると,指定したアプリ名がService名(web)の先頭に付加され,getstartedlab_webとなっているのがわかります.
ロードバランシングされるので,ホストマシンのブラウザでlocalhost:80でアクセスするとコンテナにアクセスされ,アクセス毎にHostnameが変わることを確認できます.
さらにdocker ps で実際に立ち上がったコンテナが5つあることを確認できます.
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c39d05ca95fe username/get-started:part2 "python app.py" 7 seconds ago Up 3 seconds 80/tcp getstartedlab_web.3.xievdky2mkx38pl1foa68tzcg 002d8fe2434d username/get-started:part2 "python app.py" 7 seconds ago Up 3 seconds 80/tcp getstartedlab_web.2.z17cyc4kcavu21o6cu2pxtjfl a959c1870f87 username/get-started:part2 "python app.py" 7 seconds ago Up 4 seconds 80/tcp getstartedlab_web.1.xghoiespwuc5wu2oxqn52xxhh eebff64dc8ac username/get-started:part2 "python app.py" 7 seconds ago Up 4 seconds 80/tcp getstartedlab_web.4.y0vvq8sjj8xzau3meq98fbpfm 4ba7a3c03f56 username/get-started:part2 "python app.py" 7 seconds ago Up 4 seconds 80/tcp getstartedlab_web.5.a57ejflvl0k1ckpqs5jvu33v7
docker service ps ${service_name} でサービスに紐付いたコンテナのみを表示することもできます.
Scale the app
docker-compose.yml 内のreplicas項目を変更することで,アプリケーションをスケールできます.
変更した後,再度docker stack deploy コマンドを実行することで再起動できます.
今回はreplicasを7に変更した上で再起動します.
docker stack deploy -c docker-compose.yml getstartedlab_web
再起動後,コンテナが7つ起動しているのを確認できます.
$ docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ff8a37fa9377 username/get-started:part2 "python app.py" 18 seconds ago Up 17 seconds 80/tcp getstartedlab_web.6.umd3i06tcfq1jkeh64znr53uv fc5150a8b9ee username/get-started:part2 "python app.py" 18 seconds ago Up 16 seconds 80/tcp getstartedlab_web.7.q6kbemo6ghgjh7v45amsvcwzn c39d05ca95fe username/get-started:part2 "python app.py" 15 minutes ago Up 15 minutes 80/tcp getstartedlab_web.3.xievdky2mkx38pl1foa68tzcg 002d8fe2434d username/get-started:part2 "python app.py" 15 minutes ago Up 15 minutes 80/tcp getstartedlab_web.2.z17cyc4kcavu21o6cu2pxtjfl a959c1870f87 username/get-started:part2 "python app.py" 15 minutes ago Up 15 minutes 80/tcp getstartedlab_web.1.xghoiespwuc5wu2oxqn52xxhh eebff64dc8ac username/get-started:part2 "python app.py" 15 minutes ago Up 15 minutes 80/tcp getstartedlab_web.4.y0vvq8sjj8xzau3meq98fbpfm 4ba7a3c03f56 username/get-started:part2 "python app.py" 15 minutes ago Up 15 minutes 80/tcp getstartedlab_web.5.a57ejflvl0k1ckpqs5jvu33v7
Take down the app and the swarm
アプリケーションを停止する場合docker stack rmコマンドを実行します.
docker stack rm getstartedlab
実行後,Serviceが削除されていることを確認できます.
$ docker service ps getstartedlab_web no such service: getstartedlab_web
swarmを停止する場合は以下のコマンドを実行します.
docker swarm leave --force
以上です. このようにDockerを使ったアプリケーションのスケールは非常に簡単です.
Docker containerまとめ
概要
前記事に引き続き Docker公式ドキュメントのPart2の内容を整理
Part2 containers
Introduction
Dockerの方式でアプリをビルドしていく.
アプリケーションのヒエラルキーの下層部分であるコンテナから始めます.
コンテナの上層はserviceと呼ばれ、production環境でコンテナがどのように振る舞うのかを定義します. (Part3で取り上げる).
ヒエラルキーの最上層はスタックと呼ばれ、全てのserviceのやり取りを定義します.(Part5で取り上げる).
- Stack
- Services
- Container(このパートで取り上げる)
Your new develop environment
今まで,もしPythonアプリケーションを作る際に、まず最初にマシン上にPythonのランタイムをインストールしていました.
しかし,このやり方はマシンの環境が作成するアプリを期待通りに動作させる必要を生じさせた.
Dockerで、ユーザはイメージとして可搬性のあるPythonランタイムを利用できます.
これにより,ユーザが作成するビルドはアプリケーションコードと同様にPythonイメージも含むことができ,ランタイムと依存関係を全て保証できます.
Define a container with Dockerfile
Dockerfile はコンテナ内の環境で起こることを定義します.
ネットワーク・インタフェースへのアクセスと,ディスクドライブはこの環境内で仮想化され,システム内の他のものとは隔離されるため,ユーザは外部とやり取りするためにポートを指定し,どのファイルをコンテナ環境内にコピーするか指定します.
指定したあと,Dockerfileで定義されたアプリがどのような環境でも正常に振る舞うことを保証されます.
Dockerfile
新たなディレクトリにDockerfileを作成し,簡単なPythonアプリの環境を定義する.
# Use an official Python runtime as a parent image FROM python: 2.7-slim # Set the working directory to /app WORKDIR /app # Copy the current directory contents into the container at /app Add . /app # Install any needed packages specified in requirements.txt RUN pip install --trusted-host pypi.python.org -r requirements.txt # Make port 80 available to the world outside this containers EXPORSE 80 # Define environment variable ENV NAME world # Run app.py when the container launches CMD ["python", "app.py"]
Dockerfile内にまだ作成されていないapp.pyとrequirements.txtがあるので作成していきます.
requirements.txt
Flask Redis
app.py
from flask import Flask from redis import Redis, RedisError import os import socket # Connect to Redis redis = Redis(host = "redis", db = 0, socket_connect_timeout = 2, socket_timeout = 2) app = Flask(__name__) @app.route("/") def hello(): try: visits = redis.incr("counter") except RedisError: visits = "<i>cannot connect to Redis, counter disbled</i?>" html = "<h3>Hello {name}!</h3>" \ "<b>Hostname:</b> {hostname}<br/>" \ "<b>Visits:</b> {visits}" return html.format(name=os.getenv("NAME", "world"), hostname=socket.gethostname(), visits=visits) if __name__ == "__main__": app.run(host='0.0.0.0', port=80)
pip install -r requirements.txt によってFlaskとRedisライブラリをインストールし,アプリケーションでは環境変数のNAMEを表示させています.
これで一通りアプリケーションに必要なファイルが揃いました.
ディレクトリ配下に3つのファイルがある状態となります.
$ ls Dockerfile app.py requirements.txt
Build the app
これでアプリケーションをビルドする準備が整いました.
Dockerfileが存在しているディレクトリ上で,docker build コマンドを実行してDockerイメージを作成します.
-tオプションにより,イメージ名を指定できます.
docker build -t friendlyhello .
作成後,Dockerイメージが作られたかを確認します.
$ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE friendlyhello latest 596560250ed9 About a minute ago 148MB
Run the app
ここでdocker run コマンドによりアプリケーションを起動させていきます. -pオプションで,マシン上の4000番ポートをコンテナ内の80番ポートと紐付けた上で起動させます.
$ docker run -p 4000:80 friendlyhello * Running on http://0.0.0.0:80/ (Press CTRL+C to quit)
ここで,マシン上のwebブラウザから,localhostの4000番ポートにアクセスするとアプリケーションへアクセスできます.
-dオプションを使うことでバックグラウンドでも実行できます.
docker run -d -p 4000:80 friendlyhello
docker container ls または docker ps で,使用しているコンテナのIDなどの情報をみることができます. ポートのマッピング情報なども見れます.
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c2ee894e48ab friendlyhello "python app.py" 5 seconds ago Up 4 seconds 0.0.0.0:4000->80/tcp nostalgic_perlman
起動したコンテナプロセスを止める場合 docker container stop で行えます.
この際に止めたいコンテナのコンテナIDを指定します.
$ docker container stop c2ee894e48ab c2ee894e48ab
Share your image
作成したコンテナイメージの可搬性を実感するために,コンテナイメージを外部にアップロードしてみます.
これを行う際に必要なのは,コンテナをデプロイする際にレジストリにプッシュする方法を知ることのみです.
レジストリはレポジトリのコレクションであり,,レポジトリはイメージのコレクションです.
レジストリのアカウント毎に多くのレポジトリを作成できます.
dockerクライアントはデフォルトで,docker公式レジストリを使用します.
Log in with your Docker ID
https://cloud.docker.com/ でアカウントを作成したうえで,dockerコマンドを使ってマシン上でレジストリにログインします.
$ docker login
Tag the image
レジストリ内のレポジトリの表記は username/repository:tag となります.
タグは必須ではないですが, つけることを推奨します. なぜならタグはレジストリのDockerイメージのバージョンを表す仕組みになっているからです.
レポジトリとタグ名はコンテキストに合わせた名前をつけるべきです.
ここで,実際にDockerイメージにタグを付けてみます.
以下のような表記でタグを作成できます.
username repository TAGはそれぞれユーザによって変えてください.
docker tag image username/repository:TAG
作成したタグは docker image ls で確認できます.
$ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE username/get-started part2 16974e44583c 21 minutes ago 148MB
Publish the image
前項でDockerイメージに対するタグ付けができました.
ここで,タグをつけたDockerイメージをレポジトリにアップロードします.
docker push username/repository:TAG
アップロードしたイメージはパブリックに利用可能です.
Docker cloudにログインした上で下記のページで作成したイメージを確認できます.
https://hub.docker.com/
Pull and run the image from the remote repository
docker run コマンドでレポジトリとタグを直接指定してコンテナを起動することができます.
docker run -p 4000:80 username/repository:tag
もし指定したDockerイメージがローカルマシンに存在しない場合,DockerはレポジトリからDockerイメージをpullしてきます.
Docker Conceptまとめ
概要
DockerのConceptまわりを再度整理するために 公式ドキュメントのget-started part1の内容をメモ
1: Docker Concept
Docker: アプリケーションを開発・デプロイ・コンテナとして起動するプラットフォーム
linuxコンテナをアプリケーションにデプロイすることをコンテナ化と呼ぶ.
コンテナ自体は新しいmのではないが、アプリケーションのデプロイが簡単になるために使われる.
コンテナ化はますます人気になっている理由はコンテナが以下のような性質を持つからである.
- フレキシブル 最も複雑なアプリケーションもコンテナ化できる.
- 軽量 コンテナはホストのカーネルを共用する
- 交換性 アプリケーションのデプロイが可能で、アップグレードも行える
- 可搬性 どこでも稼働する
- スケーラブル コンテナのレプリカを自動的に増やせる
- スタック可能 サービスを垂直的にスタック可能
Images and containers
コンテナはイメージを実行する事によって起動する.
イメージは実行可能なパッケージであり, アプリケーションを実行するためのコード,ライブラリや、環境変数,設定ファイルなどを全て含んでいる.
コンテナはイメージのインスタンスのランタイムであり、イメージの内容が実行されたときにメモリ内に格納されるものである.
docker ps コマンドを使って起動中のコンテナ一覧を見ることができます.
Containers and virtual machines
コンテナはlinux上で起動し、他のコンテナとホストマシンのカーネルを共有する.
コンテナは独立したプロセスを起動し、他の実行可能なプロセス以上にメモリを消費せず,軽量である.
それとは対照的に、VMはhypervisorを介して、ゲストOSを起動し、OSより上の層も全て含む.
通常,VMは多くのアプリケーションが実際に必要とするよりも多くのリソースを提供することとなる.
2: Containers
Kubernetesのコンセプトまとめ
Kubernetes コンセプト
Kubernetesのコンセプトを理解するために公式ドキュメントを読んでざっくり整理しました。
overview
kubernetesを利用するためには kubernetes apiを使ってクラスタを意図する構成にさせる。 たとえばどのようなアプリケーションやワークロードを使うか、使用するコンテナイメージ レプリカ数、ネットワークやディスクリソースの設定などです。
kubernetes apiは、 kubectlというコマンドラインインターフェースを通じて利用します。
The Kubernetes master: クラスタ内のシングルノード上でマスターノードとして起動する3つのプロセスのコレクションのこと。
この３つのプロセスはkube-apiserver, kube-controller-manager, kube-schedulerです。クラスタ上のマスターでないノードは2つのプロセスを起動します。
kubelet: kubernetes masterとやり取りするプロセス
kube-proxy: 各ノードにkubernetes networking serviceを反映させるネットワークプロキシ
Kubernetes Objects
Kubernetesはシステムの状態を表すために幾つかの抽象概念を持つ。
Kubernetes apiの内部でこれらの抽象概念はオブジェクトとして表現されます。
主なオブジェクトは以下のとおりです。
- Pod
- Service
- Volume
- Namespace
さらに、KubernetesはControllersと呼ばれる高レベルの抽象概念も持っています。 Controllersは上記の基本オブジェクトによって構成され、さらに便利な機能を提供します。
- ReplicaSet
- Deployment
- StatefulSet
- DaemonSet
- Job
Kubernetes Control Plane
Kubernetes MasterやKubelet プロセスのようなKubernetes Control Planeの様々なパーツは、Kubernetesとクラスタのコミュニケーションを統制します。
Control Planeはシステム内の全てのKUbernetes オブジェクトのレコードを管理し、そのオブジェクトの状態を管理するために継続的なループプロセスが稼働しています。
どんなときでも、Control Planeのループプロセスはクラスタ内の変更に応答し、システム内の全てのオブジェクトが意図する状態になるために稼働します。
Kubernetes Master
Kubernetes Masterはクラスタを意図する状態に維持します。 ユーザがkubectlコマンドを使ったりしてKubernetesとやり取りする際、ユーザはKubernetes Masterとやり取りする事となります。
"Master"はクラスタの状態をマネージするコレクションの集合を意味します。通常これらのプロセスはクラスタ内の単一ノード上で稼働し、そのノードは"Master"として扱われます。
Masterは可用性のためにレプリケーション可能です。
Kubernetes Nodes
クラスタ内のノードは、アプリケーションやワークフローを稼働させるマシン(VM 物理サーバなど）を意味します。
Kubernetes Masterはこれらの各ノードを管理し、ノード単体に対して直接操作することは殆どありません。
