Go to Qiita Advent Calendar 2024 Top
LoginSignup
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@superbrothers(Kazuki Suda)in Preferred Networks (PFN)

Kubernetes v1.7: Action Required Before Upgrading

Last updated at Posted at 2017-07-19

このエントリは Kubernetes v1.7 CHANGELOG の Action Required Before Upgrading をまとめています。

その他の項目は下記を参照してください。

Network

net.beta.kubernetes.io/network-policy アノテーションによる Namespace レベルのネットワークポリシーの廃止

NetworkPolicy が extensions/v1beta1 から新たに networking.k8s.io/v1 API グループに昇格した。これにリソース構造の変更は含まれない。これに伴って v1.5 で導入された Namespace の net.beta.kubernetes.io/network-policy アノテーションによる Namespace レベルのアクセス制御が廃止された。この廃止により、NetworkPolicy は Pod レベルでの制御のみ提供されていることになる。

これまで Namespace のアノテーションによる Namespace レベルでの DefaultDeny ポリシーを利用していた場合、v1.7 では下記のような全ての Pod でアクセスを許可しない NetworkPolicy を作成することで同様のことが行える。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny
spec:
  podSelector:

Storage

volume.alpha.kubernetes.io/storage-class アノテーションの廃止

下位互換のために残されていた PersistentVolume, PersistentVolumeClaim の volume.alpha.kubernetes.io/storage-class アノテーションが廃止された。代わりに StorageClassName を利用しなければならない。volume.beta.kubernetes.io/storage-class アノテーションも廃止が予定されているため、早めに移行したほうがよい。

コメント文によると v1.5 で廃止される予定だったようだが、v1.7 まで残っていたようだ。

Portworx ボリュームドライバを master ノードで動作させる必要がなくなった

Portworx ボリュームドライバはこれまで master ノードで実行させる必要があったようだが、この制約を無くしたようだ。PR の注釈としてそもそも GKE では master ノードに Pod をスケジューリングさせることができないしとある。

この変更は特に対応が必要に思えないのだが何かあるのかもしれない。使っていないので深追いはしていないが興味ある方はそもそもなぜ master ノードで動作させなければならなかったのか追ってみると面白いかもしれない。

OpenStack Cindier StorageClass で Availability Zone がデフォルトでは存在する AZ がラウンドロビンで選択されるように変更

OpenStack Cinder StorageClass では GCE や AWS のそれと異なり、Avaialivity Zone (AZ) を明示的に指定していなければデフォルトで "nova" という AZ が利用される挙動だったが、これは例えば StatefulSet で Galera Cluster を構築する際に PersistentVolume を複数の異なる AZ で作成することができないことを意味していた。

この変更で AZ を明示的に指定していなければ全ての AZ からラウンドロビンで選択するようになる。AZ が一つも存在しなければこれまで通り、"nova" が利用される。これは gophercloud の挙動である。
https://github.com/kubernetes/kubernetes/blob/v1.7.0/pkg/volume/cinder/cinder_util.go#L198

さて、ではどこから AZ のリストを取得するかというと、Node の failure-domain.beta.kubernetes.io/zone ラベルである。このラベルは、GCE, AWS においては PersistentVolumeLabel admission Controller が自動的に付与してくれるが、OpenStack は対応していないので、クラスタ管理者が付与する必要があるようだが、コードを見る限り OpenStack で対応するのはさほど難しくなさそうだ。
https://github.com/kubernetes/kubernetes/blob/v1.7.0/plugin/pkg/admission/persistentvolume/label/admission.go#L70

PodSpec の volumes hostPath または volumeMounts mountPath でバックステップ (..) を許可しない

PodSpec の volumes hostPath でバックステップ (..) が許可されなくなった。利用していると Pod のバリデートに失敗する。

これは、Pod Security Policies と関連していて、例えば allowedHostPaths で /tmp/foo を許可していたとしても、下記に path を /tmp/foo/../../ とすることで全てのパスを操作できるようになってしまっていた。

# Pod Security Policy
spec:
  allowedHostPaths:
  - /tmp/foo/

# PodSpec
  volumes:
      - name: app-logs
        hostPath:
          path: /tmp/foo/../../

API Machinery

Namespace オブジェクトの deletecollection サポートの削除

Namespace オブジェクトの deletecollection のサポートが削除されました。もともと誤ってサポートしてしまったもののようだ。Namespace オブジェクトを deletecollection により削除してしまうと、NamespaceLifecycle Admission Control の処理がスキップされてしまう問題があるようだ。

いくつかの alpha API グループがデフォルトで有効になってしまっているが、v1.8 では無効とする

下記二つの alpha API グループが意図せずデフォルトで有効になってしまっているが、v1.8 では改めて無効になる。

  • Alpha level
    • Availability: committed to main kubernetes repo; appears in an official release; feature is disabled by default, but may be enabled by flag
  • rbac.authorization.k8s.io/v1alpha1
  • settings.k8s.io/v1alpha1

v1.8 で引き続きそれらを利用する場合は、apiserver の --runtime-config フラグを使い明示的に有効にしなければならない。

提供されるスクリプトによって v1.8 までに etcd にストアされている storageclasses を storage.k8s.io/v1beta1 から storage.k8s.io/v1 に更新なければならない

クラスタ管理者は、cluster/update-storage-objects.sh を使い、v1.8 までに etcd にストアされている storageclasses を storage.k8s.io/v1beta1 から storage.k8s.io/v1 に更新なければならない。

これは、storage.k8s.io/v1 が v1.6 にリリースされたため、storage.k8s.io/v1beta1 のサポートは6ヶ月で打ち切るということだろうが、正しくは分からなかった。

Controller Manager

kube-controller-manager の --insecure-experimental-approve-all-kubelet-csrs-for-group フラグの廃止

kube-controller-manager の --insecure-experimental-approve-all-kubelet-csrs-for-group フラグのサポートが削除された。v1.7 ではこのフラグ自体は下位互換のために削除されていないが、機能自体は有効にならない。

このフラグは、TLS bootstrapping に用いられているフラグで、kubelet からの CSR を自動的に承認するグループを指定するために使われていた。v1.7 から代わりに承認処理は csrapproving controller が行うようになり、これは kube-controller-manager の一部としてデフォルトで有効になっている。

この廃止されたフラグの動作を引き続き使うためには、クラスタを更新する前に、RBAC ClusterRole, ClusterRoleBinding を作成し、全ての CSR を同一のグループで承認されるようにしてから実行する必要がある。作成する ClusterRole, ClusterRoleBinding の例は TLS bootstrapping | Kubernetes を参照すること。

kubectl (CLI)

kubectl create role, kubectl create clusterrole で複数のリソースを指定する方法の変更

kubectl create role, kubectl create clusterrole で複数のリソース名を指定する方法が、これまで --resource-name=x,y のようなカンマ区切りから、--resource-name=x --resource-name=y のようなフラグを繰り返す方法に変更になった。

kubectl create rolebinding, kubectl create clusterrolebinding で複数のユーザ、グループ、サービスアカウントを指定する方法の変更

上記と同じく、kubectl create rolebinding, kubectl create clusterrolebinding において、複数のユーザ、グループ、サービスアカウントを指定する方法がフラグを繰り返し指定する方法に変更になった。

カンマ区切りでの指定はどうしても補完の実装が難しくなるため、このようなフラグは stringArray での実装が好ましい（個人の見解）。

kubeadm

クラスタのアップグレードでクラスタ内部リソースが更新されるようになった

kubeadm はクラスタのアップグレード時にクラスタ内部リソースが既にそのクラスタに存在していると同じものを作成しようとしてエラーになっていたが、存在しているリソースを上書きする挙動に変更になった。この結果、kubeadm は v1.6 から v1.7 への更新を kubeadm init を実行するだけで更新可能になった。

deb/rpm パッケージにおいて情報漏えいの可能性があるため、cAdvisor は 0.0.0.0:4194 でリッスンしないように変更

deb/rpm パッケージでインストールされる kubelet において cAdvisor が 0.0.0.0:4194 でリッスンしており、ノードがパブリック IP を持っていると外部から参照可能な状態になっていたため、公開されているポートを閉鎖する。今後は https://{node-ip}:10250/stats/ からのみ cAdvisor API にアクセスすることができるが、このエンドポイントは認証/認可がかかっている。

Cloud Providers

Azure: プロビジョニングされたボリュームのコンテナ権限がプライベートに変更される

プロビジョニングされた Azure Volume のコンテナ権限がプライベートに変更される。v1.6.0 から v1.6.5 の間に作成されたボリュームが存在する場合、手動で権限を変更する必要がある。

Azure を使っていないので深追いはせず。

GKE/GCE: 1.7 で新たに作成された、また更新されたクラスタは、kube-system namespace の default serviceaccount が cluster-admin ClusterRole が設定された ClusterRoleBinding を付与されていないようになる

タイトルの通り。cluster-admin の権限が 1.7 でも引き続き必要な場合は、下記コマンドを作成後または更新後に実行する必要がある。

$ kubectl create clusterrolebinding kube-system-default --serviceaccount=kube-system:default --clusterrole=cluster-admin
3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?