EKS1.19がリリースされたので改めて1.19での変更内容を確認する
EKS1.19がリリースされたので改めて1.19での変更点について個人的に注目したものメモしていきます。
す。
※ほとんどIngress関連になってしまいました。
1.18からの細かい変更点はこちらに記載があるのでこちらをご確認ください。
Deprecation warnings
非推奨なAPIなどを先に警告してくれるようになります。
これによって今まで移行の際にどのような変更が必要なのかをクラスタ管理者などは知ることはできます。
またその警告に対して大替のAPIを含んでくれるので移行などの作業が従来よりも軽減されることが期待できます。
カスタムリソースなどのAPIも警告を発してくれるようなので便利な機能ですね!
Avoiding permanent beta
1.20以降ですが、 APIのバージョンを9ヶ月以内に Beta から移行するポリシーが適用されます。
この機能によって機能が長い間Beta版として留まることへの抑止力につながります。
Increase the Kubernetes support window to one year
k8sのバージョンサポートを9ヶ月から1年に伸ばす施策です。
これによって年間のライフサイクルと同じようにkubernetsのバージョンサポートが得られます。
Ingress
1.19では晴れてIngressが GA になりました🎊
これによっていくつかの記法に変更点が加わることになるのでそれを紹介したいと思います。
apiVersionは networking.k8s.io/v1beta1
から networking.k8s.io/v1
への変更が可能になります。
それによっていくつかのフィールドの記法が変更になるので注意が必要です。
backend配下の記法の変更
Ingress は path にマッチした場合 backend で指定している Service への指定をしていましたがその記法の変更が入りました。
1.18までの記法がこちら
apiVersion: "networking.k8s.io/v1beta1"
kind: "Ingress"
metadata:
name: "example-ingress"
spec:
ingressClassName: "external-lb"
rules:
- host: "*.example.com"
http:
paths:
- path: "/example"
pathType: "Prefix"
backend:
serviceName: "example-service"
servicePort: 80
1.19ではこのような記法になります
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: sample-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
paths:
- path: /testpath
pathType: Prefix
backend:
service:
name: test
port:
number: 80
大きな変更点として spec.rules.http.paths.backend
配下の記法が変わっています。
# 1.18
backend:
serviceName: "example-service"
servicePort: 80
# 1.19
backend:
service:
name: "example-service"
port:
number: 80
# servicePortを文字列で指定している場合はこちら
backend:
service:
name: "example-service"
port:
name: "example"
このように変更されており 今まで使用されていた serviceName
と servicePort
は使用されなくなるので変更が必要です。
pathType
Ingressには pathType というフィールドが存在しており、ここに値を指定するとその pathType に応じたパスの検証をおこないます。
1.18までは ImplementationSpecific
というのがデフォルト値で入っていましたが1.19からはここの指定を必須にする必要があるのでここも注意しましょう。
他には Exact
、 Prefix
この2つの値を指定することができるので用途にあったpathTypeを選択してください。
Ingress Classの指定
今まで使用する Ingress を設定する場合は、 kubernetes.io/ingress.class
このアノテーションを指定することで任意の Ingress を使用することを決定できました。
特にこのフィールドは正式な定義ではないですが一般的に使用されているアノテーションでしたが1.18から IngresClass
属性と ingressClassName
フィールドが追加されました。
特に ingressClassName
は kubernetes.io/ingress.class
に変わるものとして使用するものとして存在しておりアノテーションに kubernetes.io/ingress.class
こちらを指定するのは非推奨となりました。
使用例はこのような形です。
-
networking.k8s.io/v1beta1
時点での記法です。
apiVersion: networking.k8s.io/v1beta1
kind: IngressClass
metadata:
name: sample-ingress
spec:
controller: example.com/ingress-controller
parameters:
apiGroup: k8s.example.com/v1alpha
kind: IngressParameters
name: sample-ingress
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: example
spec:
ingressClassName: sample-ingress #ここにIngressClassで指定した名前を使う
rules:
- host: example.com
http:
paths:
- backend:
serviceName: sample
servicePort: 80
Ingress が GA ということでそれが主題になってしまいましたが他にも魅力的な変更が多いので興味があるものがあれば追記したいと思います。
EKS1.19の変更
ここからは EKS1.19 で変更された部分について少し触れていこうと思います。
英語の読み間違えで文章の解釈を間違える可能性があるのでご容赦いただければと思います。
公式ドキュメントはこちら
重要な変更
-
EKSを新規で作成される際にサブネットのタグに対して
kubernetes.io/cluster/<cluster-name>
タグを追加しなくなります。このサブネットタグは AWS Load Balancer Controller から作成されるロードバランサーを配置する場所を柔軟に扱いたい際に必要としています。- 既存のクラスターには特に影響を及ぼさずアップグレードによるサブネットのタグの変更はないです
- AWS Load Balancer Controller v2.1.1 までは上記のタグが必要でしたが v2.1.2 以降ではこのタグを指定してサブネットの絞り込みが可能ですが必須ではなくなりました。
https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html
-
Service Account の IAMロールを使用するために Web ID トークンファイルにアクセスする非ルートコンテナに対してのセキュリティコンテキストを提供する必要がなくなりました。
-
pod identity の webhook が更新され、startup probe が欠落される問題の修正がされました。https://github.com/kubernetes/kubernetes/issues/95604#issue-722365456
-
CoreDNS1.8.0 が EKS1.19 の新しい推奨バージョンになります。新規で EKSクラスタ を作成する場合はデフォルトでインストールされます。https://docs.aws.amazon.com/eks/latest/userguide/coredns.html
-
EKS に最適化された Amazon Linux 2 AMI には Kubernetes Version 1.19 用の Linux カーネルバージョン5.4が含まれています。
-
CertificateSigningRequest API
の API がcertificates.k8s.io/v1
に昇格しました。
新機能
-
ExtendedResourceToleration admission controller が有効になりました。この admission controller を使用することで GPU を使用したい Pod が GPU ノードに自動でスケジュールされるのでユーザーが手動で操作などをする必要がなくなります。
https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration
Discussion