tshimba’s blog

このサイトの掲載内容は私自身の見解であり、所属する組織とは関係ありません

JJUG ガチKubernetes講座まとめ

先日開催されてJJUG主催のKubernetes講座【東京】JJUG ナイトセミナー 「ガチKubernetes講座＠Microsoft」 3/2(金)開催に参加してきました。

当日の資料はすべてGitHub上に公開されています。

github.com

資料を直接読み込むのが一番いいかと思いますが、当日スピーカーの方が話した内容を殴り書きでメモしましたので、以下に載せておきます。

例えばラベルにはapp, env, versionは必ず入れましょうだったり、Deploymentの設定にはネットのサンプルとして転がっているYAMLファイルでは不十分なので最低限こういうないようは記載しましょうといった内容がためになりました。最後の8章は、Kubernetes関連のHelm, Draftなど便利ツールの紹介でした。

講座中はスキップした内容もあったこともあり、すべてはメモできていないので、本エントリは概要の把握にとどめ、詳細はGitHubの原典にあたっていただければと思います。

Speaker

Yoshio Terada k8s-Azure-Container-Service-AKS--on

hackfest で蓄えたノウハウ伝授 ローカル環境にあったメモをbrash upしたもの

Kubernetesのすばらしさ - 開発者と運用者両方が協力して扱うことで発揮できる

資料はすべてGitHubに公開する

2020のプロジェクトがあるので、すべてのサービスを知っている人はいない。 常にキャッチアップをしないといけない。

About Kubernetes

  1. Master
  2. node
  3. Pod
  4. Container
  5. Service
  6. Deployment
  7. iptable
  8. ingress
  9. version
  10. namespace
  11. istio

master

master serverの重要なコンポーネント - API Server: REST を待ち受けるサーバ

node

可用性セットのVM

pod

Pod: Container間のサービスが密接に関わりがある場合

service

1 service, multi pods

deployment

replicas

labels

ラベルからこのサービスを選択可能。 ちゃんと書いていきましょう。

例： - app: account-service - env: test - version: v1

container

image: xxx <- 作成したimageの指定

iptable

version

最新 1.9.x

namespace

dev, prod, testなどで分けて使うイメージ

istio (6章)

version 0.5? まだ本番環境では速い。 istio (サービスメッシュ) はトレンドなので動向を見守る

podの中にproxyが作成される イエーガー？ 分散トレーシングして、マイクロサービスの依存関係のツリーを可視化してくれたりする サービスから個々のサービスの呼び出しにどのくらい時間がかかるのか取得できる

Kubernetes自身のネットワーク周りが弱い。Istioすごい便利 - version 1に100%処理を振るなどの指定 - 特定のheaderがあるリクエストだけがversion 2にアクセスするなど - カナリアリリース - サーキットブレーカー <- Java側でnetflixのライブラリを使用しなくてもいい。Istioでやってくれる

AzureでKubernetesを使用する場合の説明

提供形態

  • Managed: microsoft managed master servers. masterノード用のVMの支払不要。k8s のバージョンアップもコマンド一つで可能。システムを停止せずに更新可能（３，４０分程度かかる）
  • not managed: ACS is not managed. 自身でmasterノードのHAなど必要

環境構築

Mac, Windows 10は簡単 古いwindowsはVMなどを立ち上げたほうが速い

Azure cli

brew install az command

$ az aks <- kubernetes 環境構築
$ az login

AKS

まだpreview version 一部リージョンで使用可能

Azureのリソースグループの説明

$ az group create --name MCACS-AKS --location eastus
$ az aks create --resource-group MCACS-AKS --name esakscluster --node-count 5 --generate-ssh-keys
$ az aks install-cli <- credential 取得
$ kubectl cluster-info
$ kubectl version <- 1.7.7 (update later)

nodeの数

サービスにあわせてVMの数も増やす

$ az aks scale --name esakscluster --resource-group MCACS-AKS --node-count 7

version up

無停止バージョンアップが可能 Azure は1.8.7が最新、1.9.x対応準備中

$ # version check
$ az aks get-upgrades --name esakscluster --resource-group MCACS-AKS
$ # upgrade
$ az aks upgrade --name esakscluster --resource-group MCACS-AKS  --kubernetes-version 1.8.7 --yes
$ # check version
$ kubectl get node -w

構築

Dockerfile

前提知識：小さいイメージを作る java:8-jdk-alpine <- 小さい * alpineはコマンドなども変わるので気をつける。普通のUbuntuなどとは違う 注意点例１：ssl関係ライブラリが入っていない 注意点例２：useraddではなくadduser

ビルド結果のみimageに入れる

docker version 17.05 から multi stage build 複数のビルドステップを記述可能。（FROMを複数記述可能） -> DeliveryPipeline のような感じで、BUILDステップ、DEPLOYステップを分けて記述可能 * サンプルではparayaを使っている

Java SE9 以降 -> JREを自分で作れる -> より小さいimageを作れる

push image

pull image from kubernetes

Pod

本番環境で耐えられる deployment

教科書レベルのdeploymentに追加すべきこと

ラベル

ラベルは必ずつける app, env, version

rolling upgrade

今動いているコンテナに来ているアクセスはどうするのかなど、設定可能

例： - minReadySecond -> コンテナ起動後、アプリが正常に動くまで待つ - maxSurge -> 先に１個増やす - maxUnavailable -> かならず１個は残す

health check

livenessProbe

  • initialDelaySeconds: コンテナが起動しただけで正常となる（デフォルト）ことを防ぐ。healt chechまでの時間。falseだとコンテナを再起動されてしまう。
  • readinessProbe: サービスを使えるかを確認する。10秒に一回pingをかける
  • failureThreshold: X回失敗したらFailとする

リソース管理

pod 上の service は node 上のリソースを使い切ってしまう。 -> node上の全サービスに影響を与える可能性がある。

実際には負荷テストをしてから、リソースの上限を決定する

$ # get pods
$ kubectl get po
$ # 使用しているリソースを取得
$ kubectl top pod PODID
設定での指定方法
  • requests:
  • limits: （単位：1cpu = 1000m)

コンストラクタ的なもの

init Container

Podを起動前に実行する処理 Java クラスのコンストラクタ的なもの

poststart hook

prestop hook

------------------ ここまででpodが作成できました

Service

YAML要素

  • selector: ラベルをしていしてexposeする。versionなども指定可能。ex) app: account-service
  • type: 基本クラスタIPを指定する

複数YAMLをまとめる

--- で区切ってYAMLを繋げる

リリース作業

以下の手順が必要だが、毎回実行するのは大変 - build app - create image - push image - pull image ...

Shellスクリプトで記述してしまう。 （jenkisとかは使えないが、開発で頻繁にリリースする場合は使える）

---- ここまででビルド完了

動作確認

本番環境では基本クラスタIPを使用するが、特定のサービスの動作確認をしたい場合にはport forwardして単体で公開する。

YAML

YAMLを書く時に参考にできる公式の情報の調べ方

$ kubectl explain deplloyment.spec

---------- ここまで３章

4章

最低限覚えておいたほうがいいコマンド一覧 22個 -w: watchの略 -> 動的に変わる情報を閲覧する -o wide: podがどのnode上で動いているか取得する

  1. a
  2. 2
  3. config map service-name.ns-name.svc.cluster.local <- dns名でアクセス可能（直接ipでない）
  4. secret
  5. apply: 上書きできる
  6. delete
  7. edit: 一時的に設定を変える <- 一時的にサービス単体に外部IPを与える時など
  8. scale --replicas: 明示的にスケールをさせる場合
  9. auto scale
  10. kubectl config get-contexts: よく使うkubernetes環境をデフォルトに設定できる
  11. kubectl xxx: よく使うnamespaceをデフォルトに設定できる

5章

KubernetesのREST api

6章

istio

7章

Kubernetesを扱う上での注意点

タグ：latest <- latestタグを使用するのはやめてください

何がlatestなのかわからなくなってくる 必ずimageに対してはversion番号を振る kubernetesはロールバックなどもできるので、どのバージョンに戻るか指定するのが難しい（人間にやさしくない。不可能ではない）

１つのサービスを１コンテナで提供していきましょう

自分がKubernetesのどのバージョンを使用しているのか意識する

バージョンが上がるとYAMLの書き方やコマンドが変わってくる。後方互換性がなくなってくる。

Podを直接使わないでください。

* ReplicationController(Old) -> ReplicaSet(Old) -> Deployment

できるだけ小さいimageを使用する

officialはまだいいかもしれないが、人のimageは使用しない。

ClientIPを使用する

Nodeに対してアクセスできないようにする(Azure AKSではdefaultで使用できなくなっている)

Nodeが乗っ取られると最悪 必ずmaster経由でアクセスする

recordオプション

applyをするときにはrecordオプションを使用する

config map, secretを使用しましょう

8章

Kubernetesを扱う時に便利なツール

  1. Helm: 開発、デプロイ
  2. Draft: 開発時にユーザをXXのdeveloperと認識して、draft create とするとjavaと認識する？

  3. SpenNaker: CI/CD

  4. weave

# すごい細かい情報が取れる
$ kubectl port-forward -n weave　PODID
  1. Heptio Ark: Backup & Restore
  2. kube-monkey
  3. open service broker Kubernetes Service Catalog Azure: OSBA (Open service broker for Azure)