こんにちは。 @amsy810 です。

下記のブログが出てから『Kubernetes は運用しきれない』と耳にすることが多くなってきたので、雰囲気で曲解されて Kubernetes is difficult とならないよう、マネージドでシンプルに使うだけなら難しくないよと伝えるために書きました。

Kubernetes がいいよと伝えるためではありません。

TL;DR

上記のブログについては概ね同意見です。

辛いのは自前で Kubernetes クラスタの管理自体を行う場合です。

GKE などのマネージド Kubernetes サービスを利用するケースでは、Kubernetes の管理は殆ど必要がなくなります。

例えば GKE の場合には、自動クラスタアップグレード・自動クラスタスケーリングなどが用意されています。他にも自動ノードプロビジョニング機能（CPU・メモリ・GPU の割り当て要求に従って、良い感じのノードを自動でクラスタに追加・削除する）を利用すると ノードの管理ですら必要なくなり 、抽象度の高い（利便性の高い）基盤として利用することが可能です。

また、アプリケーション開発者として Kubernetes を利用するだけなら実際は非常にシンプルに利用することが可能です。

マネージド Kubernetes を使えるなら、開発者として利用するだけなのでそこまで難しくありません。

前提条件

コンテナを利用するべきかや、Nomad・ECS・Kubernetes といったオーケストレータ（あるいは Fargate など）を利用するべきか否かというところについては述べません。この辺りが必要な方向けに書いています。なんだかんだ VM のワークロードが必要というケースも多々あるでしょう。また、PaaS も良いと思います。あくまでコンテナオーケストレータだけの話をしています。

この前提は、再現性・管理性・復元力・可観測性・自動化・疎結合性といった特性を組織が享受できる状態か（享受したい状態か）どうかによって異なります。

なお、すでにクラウドを利用している組織で新規プロジェクトの技術選定なのだとしたら、ステートフルなものはマネージドサービスを利用しつつステートレスなアプリケーションに利用していくことは障壁も少なくおすすめです。

どのオーケストレータを選択すべきか

国内では選択したオーケストレーターを今後も長く使っていくケースが非常に多くなるかと思います。

海外では大規模なクラウド間の移行やプラットフォームの移行をやってのけるケースも多々あるため、その気概があるなら正直何から始めてもいいと思います。

日本にはなかなか真似できない部分ですね。

なるべく塩漬けにしたい場合には、「拡張性がある」「コミュニティが活発」「エコシステムが豊富」といったあたりの長く利用できるかどうか、やりたいことが増えた際に魔改造しないで済むかどうかという点を考慮すべきだと思います。

OSS だと下火になった際の影響が大きいため、選択肢がいくつかある際は個人的にはこういったところを重視しています。

ECS などのマネージドサービスに関しては、今後もあまり心配はないと思います。

ただ忘れないで欲しいのが、Kubernetes であっても アプリケーション開発者から見ると「シンプルにも利用可能」 であるという点です（あとで紹介します）。

でも流石に PaaS の利便性には勝てないとは思います。あくまでオーケストレータを純粋に比較した場合です。

オンプレで Kubernetes を選択するべきか？

オンプレ上で Kubernetes をやろうとするのであれば、少なくとも少人数で選択することはオススメしません。

やるとしてもサポート付きの商用 Kubernetes ディストリビューションを利用するか、Kubernetes を専門に面倒をみるチームが必要でしょう。

trivago さんのケースでも 4 人チームでオンプレ上に構築して利用するというものだったので、Kubernetes はかなりオーバーだと思います。

利用者としての Kubernetes

Kubernetes を利用するということは、 GCP・AWS・Azure といったパブリッククラウドを利用するのと近しいもの だと考えています。

そのため、当然パブリッククラウド自体を自前で構築して運用することを少人数で成し遂げることは困難です（例：OpenStack）。

一方で利用者から見るとパブリッククラウドは非常に便利かつ高機能ですね。

そのためアプリケーション開発者がどの環境でやるのが一番楽かという面では、マネージド Kubernetes サービスを利用するのが一番だと思います。

管理された Kubernetes 上でコンテナを起動させる場合、コンテナを起動させてくれる抽象度の高いマネージドサービスと余り差はない と思います。

例えば、シンプルに利用するだけであれば Kubernetes でも下記のように Deployment リソース（コンテナを起動する）と Service リソース（ロードバランサ）の2つだけを使っても達成できます。

パブリッククラウドでも全ての機能を把握して選択することはないのと同様に、そのほかのリソース（機能）に関してはやりたいことが出来た際にやり方を調べれば良いと思います。その時にできることがたくさんあった方が良いとは思います。

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
        - name: nginx-container
          image: nginx:1.13
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: sample-lb
spec:
  type: LoadBalancer
  ports:
    - name: "http-port"
      protocol: "TCP"
      port: 80
  selector:
    app: sample-app

なおCI/CD では、上記の様なマニフェストのボイラープレートを作って使い回すことが可能です。

Kubernetes を採択する規模は？

規模が大きい方が得られる恩恵は大きくなりますが、小さい規模でも恩恵は大きいと思います。

ただし、小さい規模の場合は人員も少ないため、そこを担当できる（したい）エンジニアがいるかという点につきますね。

Kubernetes は抽象度の高い環境を提供できるか？

Kubernetes も HorizontalPodAutoscaler・ClusterAutoscaler や Knative などを利用することにより、PaaS のような抽象度の高い（利便性の高い）環境を提供することは可能です。

いわゆる Fargate に近しい何かも設定次第では実現できます。

Kubernetes へ移行するべきか？

Nomad・ECS・Kubernetes など様々なコンテナオーケストレータが存在します。

ECS・Nomad のいずれも足りない機能を補う様にアップデートを重ねてきており、徐々に Kubernetes にしか無かった機能が実装されてきています。

そのため、すでに ECS や Nomad で稼働している場合には Kubernetes に移行するメリットは大きくないと思います。

既存のレガシーな環境から移行するべきかという点についても同等なのですが、もし今後もシステムが改修され続けていく状況で移行コストをかけられる様であれば移行も選択肢の一つです。

主軸としては移行しなければ開発効率が上がらないかどうかが判断材料ですね。

（余談）オンプレ上で Kubernetes をやると良いところ

基本的にオンプレ上で Database as a Service や Queue as a Service などを実現するのは運用コストや仕組みづくりが大変です。

Kubernetes の周辺エコシステムを利用することでマネージドサービスを Kubernetes 上で展開することも可能になってきています（mysql-operator、Vitess、NATS など）。

そのため、オンプレ上での Kubernetes にはプライベートクラウドの充実という可能性も感じています。

まとめ

技術選定は組織ごとに好みがあると思うので、あくまでも個人の見解です。

何を選択するにせよ、様々な情報を元に適切に判断すれば良いと思います。

雰囲気で曲解されて Kubernetes is difficult とならないよう、あくまで Kubernetes の苦手意識がなくなるためだけに、一意見として書いてみました。

まとめのまとめ（心の声）

（Kubernetes、いいよ。）

追記 (4/3 15:00)

何度も言いますが、どの環境を使っても良いと思います。コードを書いたら良い感じにしてくれるのが目的です。PaaS でも ECS でも Kubernetes でもアプリケーション開発者からしたらなんでも良いでしょう。

Kubernetes も頑張って CI/CD 整備やマニフェストを書く人がいることによって PaaS の様にして利用しています。

Kubernetes は本当に素の Platform なので、ちゃんとした CI/CD がないとアプリケーション開発に集中できる環境を提供するという目的は達成できません。そのため、あくまでもインフラや SRE にある程度知見のあるメンバーは必要でしょう。

環境を整備すると PaaS も Kubernetes も Nomad も ECS もいちアプリケーション開発者からすると透過的なのが良い形だと思います。

正直単純にオーケストレータを利用する範囲であれば、その学習コストよりもその周辺の考えなきゃいけないこの方が辛いです。

また、どのオーケストレータを選択しても従来の VM で環境を作った時にはいずれも近しい程度の学習コストはかかると思っていた方が良いです。

@amsy810's Blog

~Kubernetes / Cloud Native / Docker / etc~

Kubernetes は辛いのか？