2019-01-24 マイクロサービスのためのkubernetes活用 #DevLOVE
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のお話を伺う予定です。
この記事が参加している募集
いつも応援していただいている皆さん支えられています。