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

https://github.com/kubernetes/kubernetes/blob/3f0141edd52ab6fd7b6fe473ecceb480faf12079/CHANGELOG.md#action-required-before-upgrading

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

Kubernetes v1.7: Major Themes
Kubernetes v1.7: Action Required Before Upgrading
Kubernetes v1.7: Deprecations
Kubernetes v1.7: Notable Features 抜粋

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 ノードで動作させなければならなかったのか追ってみると面白いかもしれない。

Remove requirement to run the Portworx volume driver on master node by harsh-px · Pull Request #45518 · kubernetes/kubernetes
Kubernetes Examples for Native Portworx Volume Driver | Portworx Docs

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

Openstack cinder storageclass should support also random zone names. · Issue #44735 · kubernetes/kubernetes
Statefulsets for cinder: allow multi-AZ deployments, spread pods across zones by zetaab · Pull Request #44798 · kubernetes/kubernetes
Well-Known Labels, Annotations and Taints | Kubernetes

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 フラグを使い明示的に有効にしなければならない。

Turn off the alpha features by default by caesarxuchao · Pull Request #47690 · kubernetes/kubernetes

提供されるスクリプトによって 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ヶ月で打ち切るということだろうが、正しくは分からなかった。

Support storageclass storage updates to v1 by ncdc · Pull Request #46116 · kubernetes/kubernetes

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 を参照すること。

migrate group approver to use subject access reviews by mikedanese · Pull Request #45619 · kubernetes/kubernetes
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 のようなフラグを繰り返す方法に変更になった。

use StringArrayVar for ResourceName by xilabao · Pull Request #44950 · kubernetes/kubernetes

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

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

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

use StringArray in create rolebindings by xilabao · Pull Request #43903 · kubernetes/kubernetes

kubeadm

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

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

kubeadm: Make the creation of the RBAC rules phase idempotent by luxas · Pull Request #47081 · kubernetes/kubernetes

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 にアクセスすることができるが、このエンドポイントは認証/認可がかかっている。

Disable publicly available cAdvisor by luxas · Pull Request #356 · kubernetes/release

Cloud Providers

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

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

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

Change Container permissions to Private for provisioned Azure Volumes by brendandburns · Pull Request #47605 · kubernetes/kubernetes

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

Remove e2e-rbac-bindings. by cjcullen · Pull Request #46750 · kubernetes/kubernetes