きな粉もち.net

.NET関連仕事に携わっています。OSSのソースを読んで気がついたことを中心に呟いたりブログに投稿したりしています。最近はUiPathを使ったRPAも研究中。気軽にフォローやツッコミよろしくおねがいします! Gitはここを使っています https://github.com/kinakomotitti

Container Days × kubernetes(k8s) × 「40 topic of kubernetes in 40 minutes」メモ

この記事の目的

この記事では、
Container Daysのセッション「40 topic of kubernetes in 40 minutes」で学んだことの忘備録
を目的としています。


本題

★セッションについて

「40 topic of kubernetes in 40 minutes」のセッションでは、セッション時間の40分いっぱいを使い、k8sに関する40個のテクニックや注意事項について紹介するセッションでした。スピーカーは、Microsoftの寺田さんです。

セッションでは、初めの16topicがk8sの基本的なことについてのお話で、それ以降が運用面に関する応用的なことについてのお話という構成になっています。特に、初めの16topicについては、デモでの説明となっていて、資料には記載されていないので、そこで学んだことを中心にまとめていこうと思います。

発表で使った資料がSlideShareにアップロードされていたので、埋め込んでおきます。


★Topic 1:Docker Imageは小さく作っていく

Docker の機能である「multi-stage builds*1」を使って、Docker Imageを小さく作成するというお話です。
multi-stage buildsは、以下の役目があります。

  • Dockerfilesの読み込みと保守を容易にする
  • image サイズを小さくする

docs.docker.com
そもそも、なぜ、docker imageを小さく保たなくてはならないか?

パッと考えつかなかったので、以下のブログを参考に考えてみました。
Docker Image Size - Does It Matter? - Semaphore
Why docker images should be small

以下のブログをまとめると、以下の4つが主な理由のようです。たしかに、ローカルで遊んでいた時に、imageたちにdiskをたくさん使われて困ったことがありました。

  • pull / pushに時間がかかる
  • diskがたくさん使われてしまう
  • 無駄なコンポーネントが含まれている可能性が高い
  • 保守が煩雑になる

と、言うことで、docker imageは出来るだけ小さくするようにするのが良さそうです。また、サイズを小さくするために意識して取り組みたいのが、Dockerfileを書くベストプラクティスの実践です。参考までにリンクを張っておきます。
Dockerfile を書くベスト・プラクティス — Docker-docs-ja 17.06.Beta ドキュメント



★Topic 2:Docker build→リポジトリにプッシュするバッチを作ると便利

docker build
docker push
のように、Dockerfileを作ったあと、実際に使い始めるまでの間には、ほとんど決まりきったコマンドを実行していく必要があります。自分のよう な初学者には、それもいいですが、慣れてきた人たちには、煩わしいものですよね!
決まりきったコマンドを流す。。。bash化しておけばいいじゃん!
みたいな流れだと思いますが、そういったバッチを作成されたようです。デモを見た感じ、たしかに便利そうでした。また、Topic4にも関係しますが、このバッチを実行した時に、一緒にk8s用のDeploymentのyamlファイルも作成されているようです。ほんとに便利ですw

作ってみよう。そうしよう。

【追記:以下のGithubリポジトリで公開しているとの情報をいただきました!】
github.com


★Topic 3:secretを使ってk8sでもprivateリポジトリからimageを取得する

これw
Secrets - Kubernetes


★Topic 4:yamlはdocker buildしたときに、一緒に生成する

Topic2と関連しますが、docker image が新しくなったら、k8syamlで利用するイメージも変更しなくてはいけません。それならば、docker imageをビルドするときに作っちゃった方が効率いいよね的な感じだと思います。(yamlベースで行くと以下の部分のことです。)

apiVersion: apps/v1 
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9 # ←例えば、ココ!
        ports:
        - containerPort: 80

デモでは、実際に新しいyamlが生成されてそれをkinect last applyするところまで見せていただきました。


★Topic 5:kubectl get po -w

kubectlコマンドを使う上で知っておくと便利なサブコマンドやそのオプションについての紹介です。kubectl getコマンドで、podやserviceの状態を確認するとき、通常はコマンド実行時の瞬間における状態を確認することができます。しかし、時には、その状態が変わるところまで継続的に監視をしたい場面があります。たとえば、podを起動して、状態がrunningになるまで状態を監視したい、と言ったケースです。こういうとき、—watch or -wオプションを利用することで、継続的に監視をすることができます。tailコマンドみたいなものですかね。
これを知るまではひたすらget poを繰り返し実行してましたwとても便利なオプションです!


★Topic 6:kubectl describe po

kubectlコマンドを使う上で知っておくと便利なサブコマンドやそのオプションについての紹介その2です。podの詳細情報を出力するコマンドです。


★Topic 7:kubectl logs

kubectlコマンドを使う上で知っておくと便利なサブコマンドやそのオプションについての紹介その3です。podで実行されているコンテナのログを、コンテナ毎に確認することができます。このコマンドによって、execコマンドでコンテナの中にお邪魔しなくても確認できて、デバッグの際にとても便利です。


★Topic 8:kubectl port-foward

pod開発時に、とりあえず外からpodにアクセスして動作を確認したい場合などに利用するコマンドの紹介です。サービスを新たに作成することなく、port-fowardingを実現することができます。これで、開発時は、必要な時に必要なポートをフォワードしてpodにアクセスすれば良いということでした。

明日からはそうしよう(=゚ω゚)


★Topic 9:kubectl explain

kubernetesに関する色々な説明を見ることができるコマンドです。yamlを書いている時に、何を定義するのか、何が定義できるのかということが分からなくなった時に便利だということでした。


★Topic10:kubectl get po -v

このコマンドは、kubectlコマンド自体が上手く動かない時のトラブルシューティングに便利です。
Overview of kubectl - Kubernetes



★Topic11:Serviceを公開する時に便利な方法

kubectl edit serviceをしてcluster ipタイプのサービスをloadbalanserタイプに変更する事で、ロードバランサがある環境では、serviceに外部公開用IPアドレスが付与され、外からそのアドレスにアクセスできるようになります。注意としては、外部用アドレスが割り当てられた時点から、そのサービスは、世界中に公開されることになる点です。

知らずにazureでたくさんサービスを公開していたから、とてもドキドキします。まだ対応してないけど。。。


★Topic12:外部向けサービスは【Ingress】を使う

LoadBalanceを使わずに、外部にサービスを公開する方法についてです。Topic11に関連することですね!わかりやすくまとめらているQiitaの記事を見つけたのでリンクしておきます。
qiita.com

また、そもそも、k8sのサービスは、どんなのがあり、どのタイミングで使うべきかについてまとめられている記事もありましたので、リンクしておきます。(リンクばっかり・・・w)
medium.com

Docker、k8sのネットワーク関連についてわかりやすく解説されていたセッションの資料はこちらになります。そもそもネットワークってどうやって構成されているんだっけ・・・ってなったときにまた振り返ろうと思います。


★Topic13:kubectl SDKを使って、独自コマンド操作アプリの開発が可能

SDKが公開されているので、それを使って独自のコマンドを作成することができます。これを使って独自のGUIを作ったり、オプションをつけたりといろいろできそうです!気になるサポート言語は、c#JavaJavascript、Goなどがあります!
Client Libraries - Kubernetes



★Topic14:configMapを使って、設定ファイルを外だしする

開発環境や本番環境で違う設定情報を利用したいとき、アプリケーションの中で設定している情報を外だしして、コンテナの外から変更できるようにする仕組みです。Javaでいうところの、プロパティファイル、.NETでいうところのConfigファイルに記述しているアプリケーションごとの設定情報という認識であっているかと思います。確かに、設定ファイルに記述してしまうと、開発用コンテナと、本番用コンテナを別々に作らなくてはいけなくなってしまいます。コンテナは同じものを使い、設定情報を外から変更するだけ、という運用ができるのはとても便利だと思います。

Configure a Pod to Use a ConfigMap - Kubernetes



★Topic15:kubectxを使って、クラスタの切り替えを簡単に

複数クラスタを運用されている開発者の方に嬉しいツールです。それが、kubectx です!このツールにより、操作対象のクラスタを簡単に切り替えることができます。駆け出し冒険者の自分は、まだ1クラスタしか扱ってないのでこのメリットを享受することはできないですが、きっといつか使ってみたいです。
GitHub - ahmetb/kubectx: Fast way to switch between clusters and namespaces in kubectl – [✩Star] if you're using it!github.com


★Topic16:KUBECONFIG環境変数で、クラスタの切り替えを簡単に

kubectx以外の方法で、操作対象のクラスタを切り替える方法になります。こちらは、環境変数のKUBECOMFIGにパスを設定することで実現できるようです。まだ、複数クラスタ持ってないですが、中身の確認くらいはできそうなので確認してみます。


まとめ

個人的に一番インパクトがあったのは、サービス公開時にIngressを使うのが推奨されているところでした。これまで、k8sを使ってサービス作るとき、LoadBalancerを使ってパパっと公開していましたが、それ以外に方法があることをしれてよかったです。ここでまとめたこと以外には、発表資料に情報が載っているので、そちらも参考にしながら本番リリースができるk8sの構築を進めていきたいと思います(/ω\)



*1:Docker 17.05以上で利用可能