Kubernetes Deployments: The Ultimate GuideーPart1

Kubernetesのデプロイメント ：究極のガイド パート１

今回の記事はKubernetesのデプロイメントに関しての記事です。少し長いので4つに分けて投稿します。第一回目は基本的な kubectl run コマンドなどについてです。

たった今「docker化」されたアプリをデプロイする準備はできていますか？今回の記事は商品にコンテナをデリバーするためのKubernetesデプロイメントについてのお話をしたいと思います。

編集者のメモ：この記事は Jérôme Petazzoni氏が執筆したものです。 Jérôme Petazzoni氏は前Dockerエンジニアであり、container.trainingのクリエイターでもあります。

一番初めにKubernetesコマンドについて私たちが学んだこと、そして使用した経験として思いつくのはs kubectl runです。Dockerの使用経験のある方たちはDockerとdocker runを比較してこう思うのです。「おぉ！コンテナの実装って簡単！」

結局のところ、Kubernetesを使用すると：

それでは、ものすごく基本的な kubectl run コマンドを走らせるとどうなるか見てみましょう。

$ kubectl run web --image=nginx
deployment.apps/web created

OKです！それでは、クラスター上で何が生成されたかチェックします。そして…

$ kubectl get all
NAME                       READY     STATUS    RESTARTS   AGE
pod/web-65899c769f-dhtdx   1/1       Running   0          11s
NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   46s
NAME                  DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/web   1         1         1            1           11s
NAME                             DESIRED   CURRENT   READY     AGE
replicaset.apps/web-65899c769f   1         1         1         11s
$

コンテナを獲得する代わりに、私たちは得体のしれないものを手に入れました：

• デプロイメント(この例ではウェブと呼ばれている)
• レプリカセット (web-65899c769f)
• ポッド (web-65899c769f-dhtdx)

注：上の例にあるkubernetes と名前のついたサービスは無視してください。それはkubectl runコマンドが実装される前に既に存在していたものです。

ただ私はコンテナが欲しかっただけなんです！なぜ３つの違うオブジェクトを獲得するのですか？

端的に言えば、それらのKubernetesオブジェクトは、着実にデプロイができているということを確実にしています。自分のアプリケーションを中断することなくロールバックとスケールできることも確実です。

これは、一見「それで、何が重要なの？」と思えるような状況ですが、一旦全体的な図が分かれば、それぞれのコンポーネントの役割や目的が理解できるでしょう。

実際、自分たちがシステムを設計するような役割を申し付けられているとしたら、多くの人々は結局似たようなことを思いつくでしょう。

CI（継続的インテグレーション）があれば自分のコードに自信が持てるようになります。その自信をリリースプロセスでも生かせるように、とても慎重にデプロイメントのオペレーションを実行する必要があります。

Containers and pods

Kubernetesにおいては、一番小さなデプロイメントのユニットはコンテナではなく、ポッドなのです。ポッドは、同じマシン上で走る単なる数個のコンテナのグループ（１つのコンテナのグループの時もあります）で、一緒にいくつかのものを共有しています。

例えば、ポッドの中のコンテナはlocalhostを通じてコミュニケーションを取ることもあります。ネットワークの観点から見るとこんてコンテナの中のすべてのプロセスはローカルです。

しかし、私たちはそれ単体で機能するコンテナを生成することは絶対に不可能です。それに近いことで私たちができるのは、ポッドの生成です。単一のコンテナを入れたポッドです。

それがここで起きていることです。Kubernetesに「NGINXを作って！」と言うとき、私たちは「ポッドがほしい、nginxイメージを使った単一のコンテナがあるはず」と言うと思います。

# pod-nginx.yml
# Create it with:
#    kubectl apply -f pod-nginx.yml
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
containers:
- image: nginx
name: nginx
ports:
- containerPort: 80
name: http

いいでしょう。それでは、ポッドを手に入れましょう。レプリカセットとデプロイメントの理由は？

Declarative vs imperative

Kubernetesはdeclarative なシステム（declarativeの反対語がimperativeです。）です。declarative というのは注文できないという意味です。「このコンテナを実装して」と命令することはできません。何がほしいか、を表現することだけはできます。そしてKubernetesが私たちが持っているものに対して、してほしいことのためにアクションを起こすのを待つのみです。

言い換えれば、「黄色のドアのついている12メートルの青色のコンテナが欲しい」と言って、Kubernetesがそのコンテナを探してきてくれるということです。もしそのようなコンテナが存在しなければ、作ってくれます。もし既にそういったコンテナがあるけれどもドアの色が赤で本体が緑色だったとしたら、希望する色（黄色のドアと青色のコンテナ）に塗り替えてくれます。もし、すでに理想の色と大きさのコンテナがあったとしたｔら、Kubernetesは何もしません。というのも、ほしいものが既に手に入っているからです。

ソフトウェアのコンテナの設定においては、「ウェブと名前の付けられたポッドが必要で、その中には単一のコンテナがあり、 nginx イメージを走らせてくれる」ということになります。

もしそのポッドがまだ存在しないなら、Kubernetesがポッドを生成してくれます。もしポッドがすでにあって、自分たちのスペックにぴったり合うのであれば、Kubernetesは何もする必要はありません。

それを念頭において、どのように自分たちの web アプリケーションをスケールするのか、多様なコンテナかポッドの中で走るのか？を見ていきましょう。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。