Day2
自分用参加・聴講メモ
※Keynoteは省略
Deep Dive into Autoscaling
資料公開されているが、パワーポイント
会場が移動していて遅刻したので、途中参加
ClusterAutoscalerの動作や設定の最適化について説明
ClusterAutoScaler: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler
CAは次のように拡張ができる
またTuningもできる
起動オプションに引数を渡す形のようだ
※この時点でManaged Kubernetesには使えなさそう
パブリッククラウド側で入れず、自分で入れれば調整できるのだろうか……
オプションの一覧はここから確認できる
https://github.com/kubernetes/autoscaler/blob/589cd2af9c25088ce3408eeb88ba9239201d005d/cluster-autoscaler/FAQ.md#what-are-the-parameters-to-ca
感想
ClusterAutoscalerはGKEで活用しているのでお世話になっているが、今回はCAの設定の深掘りだった
Managed KubernetesなのでCAの設定変更はできそうにないので、業務には直接役に立たなさそうなのが残念だが、CA一つとってもこれだけチューニングポイントがあって奥が深いと感じた
Deep Dive Into API Machinery
KEPの説明がメイン
Immutable fields
https://github.com/kubernetes/enhancements/blob/6f42c8560c2c36fde3730fcb0d882b2451cdc00d/keps/sig-api-machinery/20190603-immutable-fields.md
Priority and Fairness for API Server Requests
https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md
感想
KEPの内容を事前に把握してなかったので、正直発表時の内容はさっぱり分からなかった
とりあえずKEPをじっくり読んでからまた発表内容の資料が上がったら振り返ろうと思う
Writing a Kubernetes Operator: the Hard Parts
OperatorとはCRD + CustomControllerの組み合わせ
CRDのYAMLをapi-serverに投げて登録して利用できる
Reconcileを実装して、ControllerはReconciliation Loopを実行する
Operatorを作るには、ToolとLibraryがある
それがkubebuilderとcontroller-runtime
(Operator SDKは出てこなかった)
api-serverはCache Readerを使う
※裏側がInformer
CacheがsyncするまではList APIを使ってもPodを取得できないことがある
Loopで実行されるので、条件判定がしっかりしていないとおかしなことが起こる
resourceVersionとEventが衝突すると、エラーがapi-serverから返る
Cacheは次のようにCache Syncを待つ
if !expectations.Satisfied() {
// cache is not up-to-date yet
return
}
err := client.Create(&pod)
// expect the Pod to be created
expectations.ExpectCreation(pod)
Best Practice
・確定的な命名規則をする
・古いキャッシュがあることを想定する
・Reconcileは冪等を保つ
次のような比較をすると、KubernetesのMutatingで(勝手に)挿入されるMetadataなどで差分が出てしまう
if !reflect.DeepEqual(expected, actual) {
// need to update
// ...
}
かと言って、以下のようにするわけにもいかない
if sameLabels(expected, actual) &&
sameAnnotations(expected, actual) &&
sameReplicas(expected, actual) &&
sameResourcesLimits(expected, actual) &&
sameEnvVars(expected, actual) && ...
そこでHashを取得して、Hashで比較をする
// annotate object with its hash
hash := HashObject(expected)
expected.Annotations[ResourceHash] = hash
// compare expected vs. actual hash
actualHash := actual.Annotations[ResourceHash]
if actualHash != hash {
// need to update
}
StatefulSetについて
現在、PVのVolume SizeをResizeする機能はない(KEPで進行中)
WorkaroundでResizeさせることはできる
StatefulSetを使う必要はない
PodとPVCを直接扱える....実際に(Elasticは)やったとのこと
感想
ElasticでOperatorを書いてきた知見で、キャッシュ周りの扱い方・実装面でのReconcileの考え方などが興味深かった
最後のStatefulSetを使う必要はない、という考え方は過激だが面白かった
Helm 3 Deep Dive
Helm3でTillerがなくなったことで、Securityの問題をパスした(これまでTillerが管理者権限だった)
・Chart Change
・Chart Repository
・Release Upgrade Strategy
・Test framework
・OCI registry support
Chart Change
Chart.yamlにapiversion, type(application or library), dependenciesが追加
Json Schemaを使ったValue Validationも追加。helm install, helm upgradeなどのコマンド時にValidate
Chart Repository
HelmHubに公式Chartが集まっている
Helm HubへのHelmでの検索に更新が入った
Release Upgrade Strategy
Helm2ではChartをインストールした後にK8s上のObjectに変更を加えてもHelmはそれを考慮していなかった
Helm3ではCluster上のステータスを考慮するようになった
Test framework
ジョブとしてテストを実行
Hookが変更
オプションが変更
OCI registry support
OCI baseのRegistryにPushできるようになった(まだ実験的な機能)
アーキテクチャの変更
Tillerの廃止(The universe is safe again)
Helm Clientがkube-apiserverと直接やり取りする
helm initコマンドがなくなった
Release(Chartのデプロイ単位)はSecretとして保存される(デフォルト)
ReleaseのNamespaceに保存される
CRDの変更
CRDはインストールだけ実行
crds/にディレクトリにあるCRDが自動的にインストールされる
--skip-crdsでインストールをスキップ可能
hookのcrd-installがHelm3では無視されて警告が出る
New Go SDK
CLIもSDKを使っている
Migration
Helm2のChartもHelm3で動く(!!)
Helm2とHelm3の大きな違いはアーキテクチャとインフラの変更(Tillerの廃止など)
CRDとNamespaceは例外とのこと
どのようにHelm2からHelm3にMigrationするのか？
2パターンあって
・Helm2とHelm3の共存
・Helm2 → Helm3
以下はHelm2 → Helm3用のPluginを使った例
Security
Helm2ではTillerが管理者権限を要求して、Tillerに対してSecurityを講じなければならなかった
Helm3ではTillerがなくなったことで、そのSecurity Problemがなくなった
Minikube
MinikubeはContributor募集中！
MinikubeはVMを立ててからKubernetesを構築する
流れは下記
様々なVM, Runtime, Kubernetesのバージョンをサポートしている
2019年現在でも様々な機能(Vm自動選択, 多言語対応, MultiCluster対応, オプション追加など)に対応
2020年も様々な目標があり、大きなものは下記
・Multi Node
・VMの候補にDockerを選択
・UI
Help Wanted!
感想
Minikubeも2016年から始まり、Versionも1.6を目指してどんどん成長していっています。
いつもReviewしてくれているMaintainerのGoogleのエンジニアたちの発表が見れて、話もできて感無量でした
「いつもPRをReviewしてくれてありがとう」と伝えようと思ったら「いつもPRしてくれてありがとう。良いPRだよ」と言ってくれてすごく嬉しかったです。
またコントリビュートを頑張って行こう