Kubernetes歴1週間の初心者から見た景色 #AWS

機械学習のKubeflowというものに興味があってKubernetesの勉強を始めた。1週間くらい触ってみた感想をまとめてみる。

コメントや補足あれば遠慮せずどうぞ。Kubernetes歴〇年の先輩方お待ちしております。

1. 読み方がよくわからん

Kubernetesで最初に躓くポイントはおそらく読み方だろう。
KubernetesそのものはGoogleの人が下記の通りTweetしているので統一されているはず。

@imdsm @gregde @francesc @jbeda @developerluke most people on the team say: koo-ber-net-ees, or just 'k8s' or k-eights
— brendandburns (@brendandburns) April 7, 2015

問題はそのほかのKube◯◯◯ファミリーだ。ここは海外でも色々議論がされているが、決定打になりそうなTweetがいくつかある。

kubectl is pronounced "kube control" not "cube control". It's Kubernetes not Cube-rnetes. Regardless of whatever Brian Grant says. Don't @ me
— Ian Lewis (@IanMLewis) October 4, 2018

Canonical pronunciation of “kubectl” is kube-control, not kube-cuttle ... @bgrant0607 keeping us honest as #KubeCon last keynote speaker. Reminds of Bill Shannon for JEE va #JavaEE ;) pic.twitter.com/dAo5gc5pMj
— Arun Gupta (@arungupta) December 8, 2017

結局のところあまり統一されていないようだ。ただYoutubeの動画を見ると、キューブ〇〇と発音している人が多い気がする。

僕は考えた結果、Kubernetesは明確に”ク”、それ以外は気持ちcuっぽく"クュ"¹と発音することにした。

代表的なものをまとめるとこうなる。

単語	読み方	補足
Kubernetes	クーバネテス	koo-ber-nay'-tace
Kubectl	クューブコントロール	koob-control
Kubelet	クューブレット	-
Kubeadm	クューブエーディーエム	-
KubeCon	クューブコン	-

2. 学習コスト、特に初期コストが高い

参考書やWeb上の入門記事を読むと最初はひたすら環境構築から始まる。
正直「Kubernetesって結構めんどくさいな」と思ってしまう人が多数だろう。
僕もその一人だった。

もし今その時の自分にアドバイスを送れるならこうだ。
"kubectlが出来るようになるまで何とか頑張れ"

kubectlが出来るようになればKubernetesの世界での可動域がぐっと広がる。極端なことを言ってしまうとkubectlでyamlファイルをゴニョゴニョするところからがスタートラインだと思う。

Introduction · The Kubectl Book

Kubernetesを触る前はダッシュボード²とかでクールに操作できると思っていたが、現実はコマンドをいろいろ送信するという地味な作業だった。

3. kubectl apply したときに成功したかどうかわからない

さぁ、ようやくkubectlというスキルを身につけたが、次の問題にぶつかる。

▶kubectl apply -f xxxxxx.yml
pod "xxxxxx" created!

やったー！成功だ！どれどれ確認してみよう。

$kubectl get pod
NAME                         READY   STATUS         RESTARTS   AGE
nginx-pod                    0/1     ErrImagePull   0          6s

ErrImagePull！でうまく起動していない！！

どうやらDockerイメージのpullが失敗しているようだ。

kubectlのapplyが成功したからといって本当に動いているかどうかは保証されない。結局kubectl get xxxして確認しないとダメらしい。

ついでに各リソースを消す時も

▶kubectl delete -f xxxxxx.yml
pod "xxxxxx" deleted

とだけ表示されるだけだ。
ホントに全ての関連リソースが消えたのか？依存関係で不具合が起きないか？自分で確認しないといけないのか…

4. yamlの書き方がわからない

yamlファイルを自分で書けば、コンテナの設定や構成を自由に制御できるのはわかったぞ。早速書いてみよう。
とりあえずサンプルコードを確認…


apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

コンテナ３つで…
LBをつけて…
あとはコンテナイメージも自分の作ったやつにしないとなぁ…

んー…どこをどう直せば良いんだ？

Githubかどこかでyamlファイルが配布されていればサルでも環境構築できる。
だが、自分で書こうとするとまずどこにどう手をつければいいのか途端にわからなくなる。

この書き方で大丈夫？
矛盾とかないか？
こんな簡単で大丈夫？

そもそも宣言型管理に慣れていないから、初手が指せないんだよなぁ。

特にapiversionはそもそもそれが何なのかわかっていないので、一行目からどうすればいいのかわからなかった。

結論としては
kubectl api-resources
で自分の作りたいリソースに応じて確認すると言うことらしい。³

色々探しているうちにKubernetes YAML Validationというサイトを発見した。めちゃ便利。

5. 具体的なデモが少な過ぎる

yamlファイルの作法はわかったし、頑張れば色々自分でカスタマイズできそうだというのはわかった。だが、自分の描く構成をyamlファイルに落とし込むにはどうすればいいか、まだまだ具体的なイメージがわかない。

なんか良さげなデモはないのか？

企業での導入事例はたくさんあるけど、具体的にどういう設定or構成でやればいいのかは謎に包まれている。
初心者的に見たいのはyamlファイルの書き方とかdockerファイルの中身の方だ。コンテナのポートの開け方とか。kindの指定とか。

Nginxをデプロイしてデモ画面を表示する。ほうほう、それで終わり？
それだけではkubernetesの凄さがわからない。
自動ヒーリングやスケーリングをさせるデモとかないかね。

6. クラウドマネージドサービスとの連携が難しい

Kubernetesはオープンソースなのでいろんなクラウドでサービス化されている。

今回はAWSのEKSというマネージドサービスを触ってみたが、Route53やVPCの設定はめんどくさかった。CloudFormationで環境構築は自動化出来るとはいえ、Kubernetes初心者はどんなリソースが何のために作成されるのかを理解しなければならないので結局時間がかかる。

あと認証周りは本当にめんどくさい。オープンソースを持ってきてそのままくっつけた合体ロボ状態だ。ドキュメントも未整備で体系的にまとまっていない気がする。ここらへんはやっぱりGCPの方がスマートに使えるのだろうか…？

下記のワークショップで一通りの作業は紹介されているが、AWSの基礎知識がある程度身についている人向け。

Amazon EKS Workshop :: Amazon EKS Workshop

ALBの設定とか未だによくわからないので要勉強。

7. コスト感覚が掴みにくい

これまたEKSで申し訳ないが、Kubernetesを使うとEC2やらCloudWatchやらいろんなリソースが複合的に生成される。

それ一体いくらくらいかかるんだ？

EBSとか一緒に消えるの？自動ヒーリングとか言ってゾンビみたいに復活しないよね？

yamlファイル一撃でいろんなリソースが生成されるので、コスト感覚が把握しづらい。
おそらくここはGCPだろうがAzureだろうがIBMだろうがAlibabaだろうが変わらないところだと思う。

yamlファイルでリソースに自動でタグ付け出来ればコストの追跡もしやすいが…

ここも今後調査しないといけないところか。

8. 情報の陳腐化が速い

色々勉強してきて最終的に思ったのがこれだ。

この知識いつまで通用するの？

Kubernetes自体の開発サイクルが速いため、ウェブ上の入門記事や参考書はトコロドコロ古い部分がある。
毎月のようにミートアップがあるし、Slackの投稿も鬼のように溜まる。正直ついていくの結構キツい…

頑張って身につけた知識が一年後には「あ、それもう使えませんよ。こっち使ってください。」となってしまいそうだ。

これはkubernetesに限ったことではないと思うが、Qiitaの記事や個人のブログを盲目的に信頼するのは良くないと実感した。⁴

きっとこの記事自体もすぐに陳腐化してしまうのだろう。

当たり前だが、一番信頼できるのは公式ドキュメントだ。

公式ドキュメントを読もう。
Kubernetesドキュメント - Kubernetes

九州の”キュ”ではなく、FuckYouの"キュ"。気持ち喉の奥の方で「ュ」を絞り出す感じで。 ↩
各メトリクスを確認するダッシュボードはあるみたいなんだけど ↩
Kubernetesの apiVersion に何を書けばいいか - Qiitaこの記事が参考になりました。感謝。 ↩
Qiitaではしっかりと「上部に出てくるこの記事は〇〇年前のものです」と出てくるから素晴らしい。 ↩