Help us understand the problem. What is going on with this article?

KubeCon NA 2019(Day2) 参加メモ

Day2

自分用参加・聴講メモ
※Keynoteは省略

Deep Dive into Autoscaling

資料公開されているが、パワーポイント
会場が移動していて遅刻したので、途中参加

ClusterAutoscalerの動作や設定の最適化について説明

ClusterAutoScaler: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler

CAは次のように拡張ができる

084A80F7-14FA-4AEB-90B6-7C710B091B3C.jpeg

またTuningもできる
起動オプションに引数を渡す形のようだ
※この時点でManaged Kubernetesには使えなさそう
パブリッククラウド側で入れず、自分で入れれば調整できるのだろうか……

20AC1BE6-9A04-4FA8-B280-D00805DF353A.jpeg

469B4DAB-37F4-4943-811C-D73B0C174786.jpeg

オプションの一覧はここから確認できる
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を使っている

スクリーンショット 2019-11-20 午後4.44.58.png

Migration

Helm2のChartもHelm3で動く(!!)
Helm2とHelm3の大きな違いはアーキテクチャとインフラの変更(Tillerの廃止など)
CRDとNamespaceは例外とのこと

どのようにHelm2からHelm3にMigrationするのか?
2パターンあって
・Helm2とHelm3の共存
・Helm2 → Helm3

以下はHelm2 → Helm3用のPluginを使った例

スクリーンショット 2019-11-20 午後4.50.27.png

Security

Helm2ではTillerが管理者権限を要求して、Tillerに対してSecurityを講じなければならなかった
Helm3ではTillerがなくなったことで、そのSecurity Problemがなくなった

Minikube

MinikubeはContributor募集中!

MinikubeはVMを立ててからKubernetesを構築する
流れは下記

スクリーンショット 2019-11-20 午後5.15.40.png

様々なVM, Runtime, Kubernetesのバージョンをサポートしている

スクリーンショット 2019-11-20 午後7.44.35.png

2019年現在でも様々な機能(Vm自動選択, 多言語対応, MultiCluster対応, オプション追加など)に対応

2020年も様々な目標があり、大きなものは下記
・Multi Node
・VMの候補にDockerを選択
・UI

Help Wanted!

感想

Minikubeも2016年から始まり、Versionも1.6を目指してどんどん成長していっています。
いつもReviewしてくれているMaintainerのGoogleのエンジニアたちの発表が見れて、話もできて感無量でした
「いつもPRをReviewしてくれてありがとう」と伝えようと思ったら「いつもPRしてくれてありがとう。良いPRだよ」と言ってくれてすごく嬉しかったです。
またコントリビュートを頑張って行こう

Why do not you register as a user and use Qiita more conveniently?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away