2018年8月20日からGKEのマスターノードのVersionが1.8.xは1.9.7に、1.9.xは1.10.6に上がりました。
ノードの自動アップグレードをonにしているクラスターは何もしなくても、ワーカーノードのVersionも上がってることかと思います。
ただ、バージョン上がると急に期待している動作と違う挙動が見られることもあります。
例えば、v1.9.7ではgcePersistentDiskのSubPathマウントがうまくいかず、Podが起動しないという事象が起こり得ます。
本番運用しているシステムでワーカーノードの自動アップグレードはリスクがあります。
そのため、マスターノードがバージョンアップしたタイミングで、新しいバージョンのノードプールを作成し、Podを新バージョンのノードプールで起動するのを確認していく方法を取るというプロジェクトが多いのではと思います。
バージョンアップに際し、変更点を認識することが必要です。ということで、ver.1.9.xになることでどのような変化があるのか調べてみました。 deploymentなどのワークロードがGAになったこともあり、デフォルト値の変更などが気になるところです。
以下を参考にいたしました。 気になったことがあれば順次拾っていきます。
Workloads API
kindがDaemonSet, Deployment, ReplicaSet, StatefulSetのapiVersionがextensions / v1beta2からapps / v1へと変更になります。今後、apps / v1への開発は行われるが、その前のバージョンには行われないようなのでこの機会にマニフェストを変更しておきたいところです。apiVersionを新しくしたマニフェストをkubectl applyした後に、kubectl get deployment sample -o yamlしても
、apiVersionはextensions / v1beta1と表示されることがあります。これは、登録したマニフェストがapiServer内部で互換性のあるバージョンに関しては変換されるからです。
そして、kubectl get deployment sample -o yaml --v=6と打つと、/apis/extensions/v1beta1/namespaces/…というリソースにアクセスしていることが分かる。
実は、kubectl get deployments.v1.appsと打つと、表示されるマニフェストのapiVersionはapps/v1となり、オプションで--v=6として再度叩くと、apis/apps/v1/namespaces…というリソースにアクセスしていることが分かる。
kubectl convertを使用して、グループバージョン間でマニフェストを変換できるとのことです。以下のコマンドで変換できます。
kubectl convert -f sample_deployment.yaml -o yaml --output-version='apps/v1'
デフォルト値として、今までセットされていたものが外れているケースもある。.spec.selectorだ。今までは、デフォルト値として.template.metadata.labelsに記載された値をセットしていた。apps/v1からは明確な記載となる。
API Machinery
Admission Control
Admission webhooksがbetaになった。Admission Controllerの拡張機能。
Admission Controllerは認証・認可の後、Objectが永続化する前にクライアントからの要求を受け入れるか判定する仕組み。2種類あり、mutatingはクライアントの要求書き換え、validatingはクライアントの要求を受け入れるかどうかを判断する。
mutatingはマニフェストに、決まったアノテーションを付けたり、別コンテナ(例えばEnvoy)を付与したりできる。validatingは、マニフェストの内容やクライアントによって受容するか決められる。
Admission Webhooksはkube-apiserverにCallback先としてHTTPサーバを登録しておくと、そこにリクエストが飛んで来て、それに対してレスポンスを返すことで、Admission Controlを成立させる機能。
GKEにおいても使えそうな感じがするのですが(Istioがこの仕組み使って自動でEnvoyを配置しているため)、方法がわかりませんでした。
参考：Learn more about Admission Webhooks - Speaker Deck
Custum Resource
Custom Resource Definition (CRD)というのがbetaになった。ユーザ独自で定義したリソースのこと。knativeもこの仕組みを使っているはず。
Controllerの作成に便利なツールも出てきている(kube-builderなど)
KubernetesのCRD(Custom Resource Definition)とカスタムコントローラーの作成
Extending Kubernetes with Custom Resources and Operator Frameworks - Speaker Deck
Auth
RBAC
組み込み（デフォルト）のadmin/edit/viewロールが定義されていて、これをcluster role aggregationで使うことができる。以下のような形。以下に出てくるcronTabはカスタムリソースのため組み込みのRoleでは制御されていない。ClusterRoleなので、namespace関係なし。Roleであれば、namespaceで分割する。
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: aggregate-cron-tabs-edit labels: # Add these permissions to the "admin" and "edit" default roles. rbac.authorization.k8s.io/aggregate-to-admin: "true" rbac.authorization.k8s.io/aggregate-to-edit: "true" rules: - apiGroups: ["stable.example.com"] resources: ["crontabs"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
CLI
kubectl
kubectl cp /tmp/foo <some-namespace>/<some-pod>:/tmp/bar -c <specific-container>でremoteのファイルをlocalにcopyできるkubectl create pdbでデフォルト値をセットしなくなったらしい
Network
IPv6
IPv6対応（alpha）したとのこと。ただ、alphaの機能を使用するためには、 GKEの場合にはクラスター作成時に指定をすることが必要なので、面倒かもしれない。
CoreDNS
CoreDNSがリリース。kube-dnsの代わりに使用することもできる（1.11でデフォルトがCoreDNSだったような）
Other
–cleanup-ipvsフラグができてkube-dns起動時に既存のルールをフラッシュするか決められるように- ホストの/etc/resolve.confまたは-resolv-confに "options"を追加することでpodのresolve.confに反映させることが出来るようになった
Strorage
PersistentVolumeとPersistentVolumeClaimのサイズは0より大きくなくてはいけない。- GCEマルチクラスタでは、ノードを持たないゾーンでPersistentVolumeオブジェクトが動的にプロビジョニングされなくなります。
まとめ
1.9でBetaになった機能は拡張するためのものが多い。よりエンタープライズでも運用できるように改善されてきたイメージです。 ただ、使いどころを間違えると管理がかなり大変になりそうので気をつけなきゃですね。
記事書いてて思いましたが、まだまだ勉強が全然足らないですね…。
