続・KubernetesによるDockerコンテナ管理入門
Dockerなどのコンテナ技術を使ったクラスタ技術の1つに「Kubernetes」がある。今回はこのKubernetesにおけるネットワーク関連の設定や、コンテナのデプロイについて紹介する。
今回紹介するKubernetesは、Googleが開発を主導するコンテナクラスタ構築ツールだ（図1）。Googleのクラウドサービスでも利用できることもあり、ここ数年で急激に利用者を増やしている。その勢いから、最近ではDockerも公式にKubernetesを公式にサポートすることを表明しており、今後もますます利用者が増えると予想される。
Kubernetesについては以前KubernetesによるDockerコンテナ管理入門という記事で基礎的な導入手順を紹介しているが、今回はネットワーク管理やサービスの管理など、より実用的な環境を構築するための方法を紹介する。
なお、本記事ではテスト環境としてCentOS 7.4およびCentOS 7.4で公式に提供されているKubernetes 1.5.2を使用した。それ以外の環境の場合、設定方法などが異なる場合があるかもしれないので注意いただきたい。
Kubernetesのネットワーク機能
KubernetesによるDockerコンテナ管理入門記事ではKubernetesのネットワーク機能についてあまり触れていなかったが、Kubernetesではコンテナ間やコンテナ内外の通信を管理するための複数の機能が用意されている。まずはこういったネットワーク関連の機能について紹介しよう。
DNSの利用
ほかのコンテナと通信が必要になるようなコンテナをKubernetes内で稼動させる場合、そのコンテナに割り当てられたIPアドレスを知る必要がある。以前の記事では環境変数を使ってほかのコンテナのIPアドレスを取得する方法を説明したが、DNSを利用してほかのコンテナと通信できるように設定することも可能だ。
この方法では、Kubernetesクラスタ内でDNSサーバーを稼働させ、Pod名やサービス名とそのIPアドレスを対応付けることで、Pod名やサービス名をホスト名として利用しての通信が可能になる。KubernetesではKubernetes向けのDNSサーバーが公式に提供されており、これを利用することで簡単な設定だけでDNSが利用できるようになる。
DNS（kube-dns）の設定
記事執筆時点でのKubernetesの最新版であるKubernetes 1.9ではアルファ版機能として「CoreDNS」という機能が用意されている。ただ、まだ実験的な段階ということで、今回はそれ以前のバージョンのKubernetesでも利用できる「kube-dns」というDNS機能について紹介する。
kube-dnsはKubernetes上のコンテナ内で稼動するようになっており、ほかのコンテナと同様、設定ファイルからリソースを作成することで利用が可能になる。kube-dnsを稼動させるための設定ファイルはGitHub上で公開されている。このうちkube-dns.yaml.sedファイルをダウンロードして「kube-dns.yaml」にリネームした後、ファイル中の「$DNS_SERVER_IP」をkube-dnsサービスに割り当てるIPアドレスに、「$DNS_DOMAIN」をネットワーク内のドメイン名に置き換えれば良い。$DNS_DOMAINについてはファイル中に複数記述されているので注意したい。
ここで$DNS_SERVER_IPで指定するIPアドレスはKubernetesのapiserverの設定ファイル（/etc/kubernetes/apiserver）中にある「KUBE_SERVICE_ADDRESSES」で指定したサービス用のIPアドレス範囲内である必要がある。たとえば次のように設定されていた場合、10.254.0.0/16内のIPアドレスでなければならない。
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
また、ネットワーク内のドメイン名（$DNS_DOMAIN）は任意の名前を指定できるが、「cluster.local」などのようにドメイン名として利用できるものである必要がある。
なお、この設定ファイルのうちいくつかの項目は今回使用したKubernetes 1.5系では正しく認識されないため、次の部分をコメントアウトして利用した。
template:
metadata:
labels:
k8s-app: kube-dns
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ''
spec:
# priorityClassName: system-cluster-critical
# tolerations:
# - key: "CriticalAddonsOnly"
# operator: "Exists"
volumes:
- name: kube-dns-config
configMap:
name: kube-dns
# optional: true
containers:
- name: kubedns
編集後、次のようにしてこのファイルを使ってリソースを作成するとkube-dnsが起動し、クラスタ内から$DNS_SERVER_IPで指定したIPアドレスでアクセスできるようになる。
$ kubectl create -f kube-dns.yaml
ちなみにkube-dnsは「kube-system」というネームスペース内で稼動するよう設定されている。ネームスペースはサービスを分離する単位で、特に指定しない場合は「default」が使われる。ネームスペースが明示された場合（default以外のネームスペースが指定された場合）、kubectlコマンドでは「-n ＜ネームスペース＞」オプションで明示的にそのネームスペースを指定しない限り、そのリソースにはアクセスできない。ネームスペース一覧は「kubectl get namespace」コマンドで確認できる。
$ kubectl get namespace NAME STATUS AGE default Active 7d kube-system Active 7d
今回のkube-dnsはkube-systemネームスペース内で稼動しているので、次のようにして稼働状況を確認できる。
$ kubectl -n kube-system get pod NAME READY STATUS RESTARTS AGE kube-dns-1875453744-86v4w 3/3 Running 0 19h
また、kube-dnsにアクセスするためのIPアドレスは「kubectl get svc」コマンドでも確認できる。たとえば次の例では、「10.254.254.1」というIPアドレスでDNSサーバーが稼働していることが分かる。
$ kubectl -n kube-system get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns 10.254.254.1 <none> 53/UDP,53/TCP 2d
続いて、コンテナ内からこのDNSサーバーを使って名前解決を行えるように設定を行う。これは、各クラスタノード上の/etc/kubernetes/kubelet設定ファイル内に次の項目を追加すれば良い。
KUBELET_ARGS="--cluster-dns=＜DNSサーバーのIPアドレス＞ --cluster-domain=＜ネットワークのドメイン名＞"
たとえばDNSサーバーのIPアドレスが「10.254.254.1」、ネットワークのドメイン名が「cluster.local」の場合、次のように指定する。
KUBELET_ARGS="--cluster-dns=10.254.254.1 --cluster-domain=cluster.local"
この設定を追加後、各クラスタノード上でkubeletサービスを再起動すると設定が反映される。設定の反映後は、起動されたコンテナ内の/etc/resolv.confファイル内に指定したIPアドレスが自動的に追加され、名前解決が行えるようになる。
/ # cat /etc/resolv.conf search default.svc.cluster.local svc.cluster.local cluster.local nameserver 10.254.254.1 nameserver 133.242.0.3 nameserver 133.242.0.4 options ndots:5
ただし、kubeletサービスの再起動時にすでに起動されているコンテナについてはこの設定は反映されないので注意しよう。
ポッド/サービスに対する名前割り当てルールはkubernetsのドキュメントに記載されているが、次のようなものになっている。
- サービスの場合：＜サービス名＞.＜ネームスペース＞.svc.＜指定したネットワークドメイン名＞
- Podの場合：＜IPアドレスの「.」を「-」に置き換えた文字列＞.＜ネームスペース＞.pod.＜指定したネットワークドメイン名＞
たとえばネットワークドメインが「cluster.local」で、kube-systemネームスペース内で動作するkube-dnsには、「kube-dns.kube-system.svc.cluster.local」というホスト名でアクセスできる。
# nslookup kube-dns.kube-system.svc.cluster.local nslookup: can't resolve '(null)': Name does not resolve Name: kube-dns.kube-system.svc.cluster.local Address 1: 10.254.254.1 kube-dns.kube-system.svc.cluster.local
実際にはresolv.confで同時にサーチパスの設定も行われるため、「＜サービス名＞.＜ネームスペース名＞」というホスト名でもアクセスが可能だ。
サービスに割り当てたIPアドレスと外部との通信
Kubernetesではサービスを作成してIPアドレスを割り当てることで、Podに対し固定されたIPアドレスを割り振ることができる。しかし、基本的にはこのIPアドレスに対し外部からの接続は行えない。そのため、Kubernetesではサービスを外部に公開するために次の2つの方法が用意されている。
- LoadBalancer：外部ロードバランサーと連携させる。外部ロードバランサー側がKubernetesに対応している必要がある
- NodePort：Kubernetesのマスター/ノードの指定したポートへのアクセスを指定したサービスに転送する
LoadBalancerではサービスに直接外部からアクセスできるIPアドレスを割り当てることができるが、対応するロードバランサーが必要となる。GoogleのGoogle Cloud Platform（GCP）やMicrosoft Azureといったクラウドサービスでは対応ロードバランサーが提供されているが、そうでない環境で独自に対応ロードバランサを構築するのはややハードルが高い。そのため、今回はNodePortを利用したサービスの公開について紹介する。
NodePortは、サービスの作成時に「type: NodePort」を指定するだけで利用可能になる。サービスの設定方法については以前の記事で説明しているので割愛するが、たとえば「httpd」というPodを作成し、このPodへのアクセスを行うサービスを作る場合の設定ファイルの例は次のようになる。
apiVersion: v1
kind: Pod
metadata:
name: httpd
labels:
app: httpd
spec:
containers:
- name: httpd
image: httpd
---
apiVersion: v1
kind: Service
metadata:
name: httpd-svc
spec:
type: NodePort
ports:
- port: 80
nodePort: 30080
selector:
app: httpd
ちなみに、Kubernetesで使用する設定ファイルでは複数のリソースに対する設定を「---」で区切って1つのファイルにまとめることができる。このファイル前半（「kind: Pod」）がPodに関する設定、後半（「kind: Service」）がサービスに関する設定だ。前半のPodに関する設定では、「httpd」という名前で「httpd」イメージからコンテナを作成するよう記述している。そして後半のサービスに関する設定では、「httpd-svc」というサービスを作成し、「httpd」という名前のPodと関連付けるよう記述している。ここでは「type:」として「NodePort」を指定し、「ports」以下で「nodePort: 30080」を指定することで、30080番ポートへのアクセスを、この「httpd」Podの80番ポートに転送するよう指定している。
この設定ファイルを「svc-httpd.yml」という名前で保存し、kubectlコマンドでリソースを作成すると、「httpd」Podと「httpd-svc」サービスが作成される。
$ kubectl create -f svc-httpd.yml pod "httpd" created service "httpd-svc" created
「kubectl get svc」コマンドで作成したサービスを確認すると、このサービスに「10.254.147.51」という内部的なIPアドレスが割り当てられていることが確認できる。また、「EXTERNAL-IP」が「<nodes>」に、「PORT（S）」は「80:30080/TCP」となっており、ノードの30080番ポートへのアクセスがこのサービスに転送されることが確認できる。
$ kubectl get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE httpd-svc 10.254.147.51 <nodes> 80:30080/TCP 9m kubernetes 10.254.0.1 <none> 443/TCP 7d
ここでKubernetesのマスターサーバーから次のように30080番ポートにアクセスしてみると、httpdからレスポンスが帰ってきていることが分かる。
$ curl -v 127.0.0.1:30080 * About to connect() to 127.0.0.1 port 30080 (#0) * Trying 127.0.0.1... * Connected to 127.0.0.1 (127.0.0.1) port 30080 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.29.0 > Host: 127.0.0.1:30080 > Accept: */* > < HTTP/1.1 200 OK < Date: Thu, 15 Mar 2018 12:04:43 GMT < Server: Apache/2.4.29 (Unix) < Last-Modified: Mon, 11 Jun 2007 18:53:14 GMT < ETag: "2d-432a5e4a73a80" < Accept-Ranges: bytes < Content-Length: 45 < Content-Type: text/html < <html><body><h1>It works!</h1></body></html> * Connection #0 to host 127.0.0.1 left intact
さらに、マスターサーバーだけでなく各ノード上でも、127.0.0.1:30080へのアクセスは同様にhttpd Podに転送される。ここで注意したいのが、127.0.0.1（localhost）だけでなくそのホスト上のネットワークインターフェイスに割り当てられたすべてのIPアドレスに対し、指定したポートへの接続がすべて転送される点だ。
$ curl ***.***.***.***:30080 ←***.***.***.***はホストに割り当てたグローバルIPアドレス <html><body><h1>It works!</h1></body></html> $ curl 192.168.1.20:30080 ←192.168.1.20はホストに割り当てたプライベートなIPアドレス <html><body><h1>It works!</h1></body></html> $ curl 172.17.69.1:30080 ←172.17.69.1はDockerが使用するIPアドレス <html><body><h1>It works!</h1></body></html>
そのため、別途ファイアウォールなどの設定を行って適切に接続を管理する必要がある。
Kubernetesで管理できるリソース
KubernetesによるDockerコンテナ管理入門記事では、「Pod」と呼ばれる単位でコンテナを管理できることを解説した。この記事では1つのPodに対し1つのコンテナを割り当てていたが、Podでは協調して動作するような複数のコンテナを同時に管理することもできる。また、Podを複数のホストで動作させるための「ReplicaSet」や「Deployments」といった機能も用意されている。これらについても紹介しておこう。
複数のコンテナから構成されるPod
Podでは、「spec.containers」以下に複数のコンテナに関する情報を記述することができる。この場合、記述されたコンテナはすべて同一のノード上で実行される。次の例は、「mysql」コンテナおよび「wordpress」コンテナの2つを記述したものだ。ここではサービスを利用してmysqlコンテナに対しホスト名でアクセスできるよう設定している。そのため、実行時にはkube-dnsが動作している必要がある。
ちなみに、mysqlイメージやwordpressイメージでは環境変数を指定することで起動時にデータベースを作成したり、WordPressで使用するデータベースの設定を行う仕組みが用意されており、今回はこれを使って初期設定を行っている。
apiVersion: v1
kind: Service ←30080番ポートでwordpressコンテナの80番ポートにアクセスできるようサービスを作成
metadata:
name: wordpress
spec:
type: NodePort
ports:
- port: 80
nodePort: 30080
selector:
app: wordpress
---
apiVersion: v1
kind: Service ←mysqlコンテナにホスト名「wordpress-mysql」でアクセスできるようサービスを作成
metadata:
name: wordpress-mysql
spec:
ports:
- port: 3306
selector:
app: wordpress
---
apiVersion: v1
kind: Pod
metadata:
name: wordpress-app
labels:
app: wordpress
spec:
containers:
- name: mysql ←mysqlコンテナに関する設定
image: mysql
env:
- name: MYSQL_RANDOM_ROOT_PASSWORD
value: "yes"
- name: MYSQL_DATABASE
value: wordpress
- name: MYSQL_USER
value: wordpress
- name: MYSQL_PASSWORD
value: ＜適切なパスワード＞
- name: wordpress ←wordpressコンテナに関する設定
image: wordpress
env:
- name: WORDPRESS_DB_HOST
value: wordpress-mysql ←ホスト名でmysqlコンテナを指定
- name: WORDPRESS_DB_USER
value: wordpress
- name: WORDPRESS_DB_PASSWORD
value: ＜適切なパスワード＞
- name: WORDPRESS_DB_NAME
value: wordpress
この設定ファイルを「app-wordpress.yml」という名前で保存し、次のように実行するとPodおよびサービスが作成される。
$ kubectl create -f app-wordpress.yml
作成されたPodを確認すると、「READY」項目が「2/2」となっており、2つのコンテナが作成されていることが分かる。
$ kubectl get pod NAME READY STATUS RESTARTS AGE wordpress-app 2/2 Running 0 1m
また、「kubectl describe」コマンドでこのPodについての情報を確認すると、このPodは「centos04/192.168.1.103」というノード上で動作していることが分かる。
$ kubectl describe pod wordpress-app Name: wordpress-app Namespace: default Node: centos04/192.168.1.103 Start Time: Thu, 15 Mar 2018 21:42:28 +0900 Labels: app=wordpress Status: Pending IP: ： ：
このホスト上で「docker ps」コマンドを実行すると、次のように2つのコンテナが実行されていることが分かる。
# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES feeb99d3f22e wordpress "docker-entrypoint..." 29 seconds ago Up 27 seconds k8s_wordpress.96db94c1_wordpress-app_default_51cf0d3e-284e-11e8-b45e-9ca3ba232de0_9456f743 b7acec30d55f mysql "docker-entrypoint..." About a minute ago Up About a minute k8s_mysql.7bf8a0c_wordpress-app_default_51cf0d3e-284e-11e8-b45e-9ca3ba232de0_207dd98c
この状態でマスターサーバーの30080番ポートにWebブラウザでアクセスするとWordPressの初期設定画面が表示され、正しく2つのコンテナ間で通信できていることが確認できる。
複数のPodを稼動させ負荷分散を行う
1つのPodの設定内に複数のコンテナに関する情報を記述すると、それらのコンテナは必ず同じノード上で実行される。しかし、WordPressとMySQLの場合、コンテナ間で適切に通信さえ行えれば同一のノード上にある必要はない。また、WordPressコンテナについては複数のノード上で稼動させることができれば、それによって負荷分散を行うことができる。そこで続いては、1つのPodを複数のノードで実行させる例を紹介しよう。
1つのPodを複数のノードで実行させるには、「ReplicaSet」もしくは「Deployment」という機能を利用する。まずReplicaSetだが、こちらは指定した数のPodを自動的に作成するものだ。
ReplicaSetを利用して、WordPressを実行するPodについて2つのレプリカを作成して実行する設定ファイルは以下のようになる。
apiVersion: v1
kind: Service
metadata:
name: wordpress
spec:
type: NodePort
ports:
- port: 80
nodePort: 30080
selector:
app: wordpress
---
apiVersion: v1
kind: Service
metadata:
name: wordpress-mysql
spec:
ports:
- port: 3306
selector:
app: wordpress-mysql
---
apiVersion: extensions/v1beta1
kind: ReplicaSet ←ReplicaSetの定義
metadata:
name: wordpress-reps
labels:
app: wordpress-reps
spec:
replicas: 2 ←レプリカ数を指定
template: ←作成するPodに関する設定を記述
metadata:
labels:
app: wordpress
spec:
containers:
- name: wordpress
image: wordpress
env:
- name: WORDPRESS_DB_HOST
value: wordpress-mysql
- name: WORDPRESS_DB_USER
value: wordpress
- name: WORDPRESS_DB_PASSWORD
value: ＜適切なパスワード＞
- name: WORDPRESS_DB_NAME
value: wordpress
---
apiVersion: v1
kind: Pod ←mysqlコンテナについては単体のPodとして作成
metadata:
name: wordpress-mysql
labels:
app: wordpress-mysql
spec:
containers:
- name: mysql
image: mysql
env:
- name: MYSQL_RANDOM_ROOT_PASSWORD
value: "yes"
- name: MYSQL_DATABASE
value: wordpress
- name: MYSQL_USER
value: wordpress
- name: MYSQL_PASSWORD
value: ＜適切なパスワード＞
ここで、「kind: ReplicaSet」以下がReplicaSetに関する設定だ。作成するPodに関する設定は「template:」以下に記述する。この設定ファイルを「app-wordpress2.yml」というファイルに保存し、ここからリソースを作成すると、2つの「wordress-reps-」Podと「wordpres-mysql」Podが作成される。
$ kubectl create app-wordpress2.yml
作成されたPodについて確認してみると、「wordpress-reps-0m621」と「wordpress-reps-wvjk6」という2つのPodがあり、片方はcentos03、もう片方はcentos02というノード上で実行されていることが分かる。
$ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE wordpress-mysql 1/1 Running 0 5m 172.17.95.5 centos01 wordpress-reps-0m621 1/1 Running 0 3m 172.17.34.5 centos03 wordpress-reps-wvjk6 1/1 Running 0 3m 172.17.37.6 centos02
ちなみにReplicaSetに関する情報は「kubectl get replicaset」コマンドで確認できる。
$ kubectl get replicaset -o wide NAME DESIRED CURRENT READY AGE CONTAINER(S) IMAGE(S) SELECTOR wordpress-reps 2 2 2 3m wordpress wordpress app=wordpress
ReplicaSetを使って作成したPodを削除するには、「kubectl delete replicaset」コマンドを使用する。
$ kubectl delete replicaset wordpress-reps
Deploymentを使う
続いてDeploymentだが、こちらはReplicaSetのように複数のレプリカを管理する機能に加えて、さらにデプロイ管理機能も提供するものだ。Deploymentを利用する場合の設定ファイルは次のようになる。先のReplicaSetを利用する設定ファイルと中身はほぼ同じで、違いは「ReplicaSet」と指定していた部分を「Deployment」に変更しただけだ。
apiVersion: v1
kind: Service
metadata:
name: wordpress
spec:
type: NodePort
ports:
- port: 80
nodePort: 30080
selector:
app: wordpress
---
apiVersion: v1
kind: Service
metadata:
name: wordpress-mysql
spec:
ports:
- port: 3306
selector:
app: wordpress-mysql
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: wordpress
spec:
replicas: 2
template:
metadata:
labels:
app: wordpress
spec:
containers:
- name: wordpress
image: wordpress
env:
- name: WORDPRESS_DB_HOST
value: wordpress-mysql
- name: WORDPRESS_DB_USER
value: wordpress
- name: WORDPRESS_DB_PASSWORD
value: ＜適切なパスワード＞
- name: WORDPRESS_DB_NAME
value: wordpress
---
apiVersion: v1
kind: Pod
metadata:
name: wordpress-mysql
labels:
app: wordpress-mysql
spec:
containers:
- name: mysql
image: mysql
env:
- name: MYSQL_RANDOM_ROOT_PASSWORD
value: "yes"
- name: MYSQL_DATABASE
value: wordpress
- name: MYSQL_USER
value: wordpress
- name: MYSQL_PASSWORD
value: ＜適切なパスワード＞
このファイルを「app-wordpress3.yml」として保存し、実行する。
$ kubectl create -f app-wordpress3.yml
作成されたPodを確認してみると、ReplicaSetを利用した場合と同様に異なるノード上で2つのwordpressコンテナが実行されている。
$ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE wordpress-2562138459-ksg28 1/1 Running 0 45s 172.17.35.5 centos04 wordpress-2562138459-vtcm2 1/1 Running 0 45s 172.17.95.5 centos01 wordpress-mysql 1/1 Running 0 45s 172.17.37.6 centos02
DeploymentがReplicaSetと異なるのは、Podのローリングアップデートを行える点だ。たとえば、設定ファイルを編集してwordpressコンテナのイメージを「wordpress」から「wordpress:fpm」に変更したとしよう。
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: wordpress
spec:
replicas: 2
template:
metadata:
labels:
app: wordpress
spec:
containers:
- name: wordpress
image: wordpress:fpm
変更した設定ファイルは、「kubectl apply」コマンドを実行することで反映できる。
$ kubectl apply -f app-wordpress3.yml service "wordpress" configured service "wordpress-mysql" configured deployment "wordpress" configured pod "wordpress-mysql" configured
すると、起動中のwordpressコンテナを残しつ、新たなコンテナを作成し、新たなコンテナの作成完了後に古いコンテナが削除される。
$ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE curl 1/1 Running 2 2h 172.17.34.4 centos03 wordpress-1833837272-d8705 0/1 ContainerCreating 0 8s <none> centos01 wordpress-1833837272-xj2n2 0/1 ContainerCreating 0 8s <none> centos03 wordpress-2562138459-ksg28 1/1 Running 0 4m 172.17.35.5 centos04 wordpress-mysql 1/1 Running 0 4m 172.17.37.6 centos02
$ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE curl 1/1 Running 2 2h 172.17.34.4 centos03 wordpress-1833837272-d8705 1/1 Running 0 2m 172.17.95.6 centos01 wordpress-1833837272-xj2n2 1/1 Running 0 2m 172.17.34.5 centos03 wordpress-mysql 1/1 Running 0 7m 172.17.37.6 centos02
ちなみにDeploymentではReplocaSetを利用してコンテナ世代管理を行っており、アップデート前のコンテナを定義していたReplicaSetはアップデート後も残される。これを利用することで、不具合発生時にロールバックなどの操作を行うことも可能だ。
$ kubectl get replicaset NAME DESIRED CURRENT READY AGE wordpress-1833837272 2 2 2 2m wordpress-2562138459 0 0 0 7m
Deploymentで作成したPodは、「kubectl delete deployment」で削除できる。
$ kubectl get deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE wordpress 2 2 2 2 9m $ kubectl delete deployment wordpress deployment "wordpress" deleted
独自にKubernetesクラスタを構築するのはそれなりに大変
さて、以前の記事と合わせて独自にkubernetesクラスタを構築する方法について紹介してきた。これで、kubernetesクラスタを構築して運用する最小限の環境は構築できるはずだ。ただ、実際にkubernetesクラスタを構築・運用していく場合、それなりに手間がかかる点には注意したい。ドキュメントについても、Google Cloud Platform上で利用するための情報は多いものの、それ以外の環境で利用するための情報はやや不十分に感じられた。
また、実運用時に大きな問題となるであろう点はロードバランサの設定だろう。前述の通り、ロードバランサを独自のクラスタで使用するためには煩雑な設定が必要となる。技術的な詳細はサイバーエージェントの技術ブログが詳しいが、現状ではこの問題を簡単に解決する方法はないようだ。
また、Kubernetesは複雑なiptablesルールを生成してネットワークトラフィックの管理を行うため、問題が発生した際のトラブルシューティングが困難になることも考えられる。
とはいえ、Dockerも標準でクラスタ環境としてKubernetesをサポートするなど、コンテナクラスタインフラストラクチャとしてはKubernetesは事実上標準に近い状況になりつつある。今後のアップデートでこうした問題を解決する手段が提供されることを期待したい。