2019/01/24 に開催された マイクロサービスのためのkubernetes活用 のイベントレポートです。

●イベントのテーマ
　今回はエンジニア向けに 2 時間で Kubernetes (k8s) をある程度理解し、実際に開発・運用で使えるようになるためのセッションです。

　k8s は開発者のためのツールでも、運用者・インフラ担当者のためのツールでもなく、DevOps (開発者と運用者) の両方の視点と、両方にとってのメリット・デメリットを理解しなければ、正しく運用はできない製品と考えています。

　本セッションでは、開発者からみた k8s の操作方法や、運用者が開発者に求める実装方法、また k8s を運用していく上で必要となる設定などについてご紹介します。

　また、VM のインストールやオーケストレーションツールの環境構築が不要で瞬時にコンテナを起動できる Azure の機能についてもご紹介します。

●対象者
　なお、本セッションはDocker やコンテナ技術に関してある程度理解している方を対象とするため、Docker コマンドや Docker リポジトリの利用方法など基礎的な内容は取り扱いません。参加希望の方は大変恐れ入りますが、事前に学習の上ご参加ください。

■マイクロサービスのためのkubernetes活用

寺田 佳央 さん

●kubernetesは銀の弾丸ではない
・k8sはEnterprise Javaにそっくり
　　持っているノウハウが活かせる

・k8sはDevのツールでも、Opsのツールでもない
　　Devは、Opsを気にしてつくる
　　Opsは、チェックする

・どこでk8sがマッチするか
　　より早くサービスを展開していきたいところ
　　-> マイクロサービス化する必要があるところ

・k8sは銀の弾丸ではない
　　良いところは沢山ある
　　うまく使おう

・やりすぎ感を感じている
　　2000以上のプロジェクト
　　全部を追うのは無理
　　マッチするところで使えば良い

・今日はコードとデモでk8sのおいしいところを紹介

・最新技術は、英語力がエンジニアの力
　　翻訳した記事の時点で、1つ遅れた情報を読んでいる
　　英語の記事を読むスピードが、新しい情報を取り入れるスピードに直結

■3. Kubernetes-Workshop

●docker
・毎回同じだからスクリプト化しよう
　　mvn clean package
　　docker build
　　docker tag
　　docker push

・multi stage build したりします

・docker tag に latestは使わないで！
　　ビルド番号でもOK

●Pod
・このおかげでside carパターンが実現できる
　　istio
　　　　-> Proxyで処理する
　　　　-> AOPと同じ　　
　　init container
　　　　-> appを動かす前にDBのaccess checkとか
　　　　-> @PostConstract, @PreDestroy と同じ

●Deployment
・Pod単体では落ちたら終わり
　　Deploymentを把握しよう！
・DeploymentとReplicasetなど学ぶ時期で違う
　　調べると引っかかる情報には古いものが含まれてしまう
　　古いversionの定義が、新しいversionで動くかはわからない

●Rolling Upgrade
・これがないと、全部Podを落として、新しいverを動かしてしまう

●Label is very important
・フィルタリングに使う
・versionで見分けるなど
　　app:account, ver:v1
　　app:account, ver:v2

●Pull Image from Private Container Registry
・secret
　　privateのdocker registryからpullするなら認証情報を保存

●LivenessProve & ReadinessProve
・LivenessProve
　　リクエストが来たら 200 OK
・ReadinessProve
　　DBまでつなげるイメージ
　　これできっちりreadyをチェックするからRolling Upgradeが活きる！

●Request Limitation
・k8sの下で動いているVMを考えよう
　　1 core = 1,000m

●Init Container
・ここが落ちたら、appは実行されない

●PostStart Hook / PreStop Hook of POD
・PODの起動前後に処理を入れられる

●Demo
・kubectl apply
　　更新される
　　kubectl create だと、deleteが必要

・kubectl get po
　　READY と STATUS をチェックしよう
　　READY: POD内のコンテナ数

・コマンドでスケールできる
　　kubectl scale deployment/account-service --replicas=3

・画面で見たいなら
　　kubectl port-forward POD_NAME LOCAL_PORT:REMOTE_PORT

・起動できなかったら　　
　　kubectl logs POD_NAME
　　kubectl describe po POD_NAME

・manifestに何を書けるんだっけ？
　　kubectl explain deployment...
　　kubectl explain service...

●Service
・内部に持っているDNSで名前解決してくれる
・selector で、labelを指定
　　kbuectl get po --selctor app=app-name,version=v1,stage=prod
　　kbuectl get po --selctor app=app-name,version=v2,stage=prod

・type
　　ClusterIP: 基本はこれ。PrivateIPが振られる。
　　LoadBalancer: PublicIPが振られる。自動でNodePortも入る。
　　NodePort

・コマンド紹介
　　kubectl get svc
　　kubectl edit svc/account-service
　　kubectl get svc -w

●Ingress
・外に公開するならこれ

・kubectx
　　クラスタの切り替えができる
　　kubens でnamespaceのデフォルトも設定できる

・virtual hostのような設定
　　ホスト名、pathで向き先を切り替えられる

●Persistence Volume
・k8s でVolumeのMountは勧めない
　　よーく考えないといけないことが多い
　　SDKを使ってS3とかに書いた方がスケールできる

・DBもManagedなものを活用した方が良い
　　volumeをmountしたら、自力でチェックが必要
　　開発なら自由に。本番は良く考えよう。

■4. Most useful kubectl command

よく使うコマンドをまとめてあります！

■5. RESTful operation

●kubectlはREST APIを叩いている
・音声clientを作って、デモしていたら
　気づかない内に 200Podくらい立ち上げていた。。。
　kubectl が固まったが、REST APIは動いた。

・kubctl cluster-info
　backup用に、AccessTokenは確認しておこう！

■JKDで話したノウハウ

・同一namespace内にUbuntu podを立てる
　　ここに exec -it POD_NAME /bin/sh すれば、問題の切り分けができる

・「できる」と「つかう」は違う
　　必要なタイミングで使えば良い、が、やがてはEOLが来る
　　作った分だけ手間がかかる

・クラスタをBlue/Greenデプロイ
　　高頻度でバージョンアップしているので
　　クラスタ自体も、つくり直せる構成の方が良い。

・クラスタ構成は小さく
　　マイクロサービスの下を支えるk8sがモノリス、って意味ないですね

・バージョンアップするなら、新しいk8sクラスタを立てよう！

・AKSならJava, JS, .NETのアプリをリモートデバッグできる
・Azure DevOpsなら数クリックでCI/CD全部入りができあがる

・k8s以外の選択肢も考えよう

k8sの全機能を使わなくて良い

■感想

すごい数の生々しいノウハウを、すごい熱量で教えていただけました！

GitHubとTerminalとホワイトボードを行き来して、コマンドと動きと構成をつなげながら説明してもらえたので、かなりイメージをつくりやすかったです。k8sを触ったことのなかったイベント運営メンバーも、どんなものかの外観が掴めたそうです。

私の参画している現場では、小さなパイロット環境でk8sを利用している段階ですが、今後、本番へ展開していくために、これまでのVMを育てる感覚から、k8sクラスタを小さく、イミュータブルに利用する文化を作っていかなくては！と再認識できました。

ワクワクする時間をありがとうございました！

次回のDevLOVEプレミアムは 2019-02-22 に、進藤 圭さん、福田 志郎さんからRPAのお話を伺う予定です。