KubeCon NA 2019(Day2) 参加メモ

# Day2

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

## [Deep Dive into Autoscaling](https://kccncna19.sched.com/event/UagF/deep-dive-into-autoscaling-marcin-wielgus-vivek-bagade-google)

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

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

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

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

![084A80F7-14FA-4AEB-90B6-7C710B091B3C.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/314463/dd42d935-7258-ff03-6299-1c4df924b7b0.jpeg)

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

![20AC1BE6-9A04-4FA8-B280-D00805DF353A.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/314463/fccec41b-df22-6793-97c6-a8d4091514f7.jpeg)

![469B4DAB-37F4-4943-811C-D73B0C174786.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/314463/e33da1c5-47b1-ca02-c409-1e602043b2f6.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](https://static.sched.com/hosted_files/kccncna19/1c/KubeCon%20NA%2019_%20Sig%20API%20Machinery%20Deep%20Dive.pdf)

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](https://static.sched.com/hosted_files/kccncna19/51/Writing%20a%20Kubernetes%20operator%20-%20the%20Hard%20Parts%20-%20KubeCon%202019.pdf)

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](https://static.sched.com/hosted_files/kccncna19/ec/helm3-deep-dive.pdf)

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を使っている

<img width="830" alt="スクリーンショット 2019-11-20 午後4.44.58.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/314463/18c2ec11-cb11-2ceb-9717-833c47f1bd73.png">

#### Migration

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

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

以下はHelm2 → Helm3用の[Plugin](https://github.com/helm/helm-2to3)を使った例

<img width="1224" alt="スクリーンショット 2019-11-20 午後4.50.27.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/314463/1b5cbd48-93aa-0d7f-7527-cf6f4e925885.png">

#### Security

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

## [Minikube](https://static.sched.com/hosted_files/kccncna19/dd/draft.pdf)

MinikubeはContributor募集中！

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

<img width="978" alt="スクリーンショット 2019-11-20 午後5.15.40.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/314463/e0d6ad62-ad73-64a9-1c77-10104387043d.png">

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

<img width="962" alt="スクリーンショット 2019-11-20 午後7.44.35.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/314463/f6864c2c-845b-de9f-370a-b8b9353eac79.png">

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

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

Help Wanted!

#### 感想

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