自宅クラスターを k8s 1.12.1 にアップグレード
自宅の PC で Kubernetes クラスターを運用し始めてから、 一年経った。
Happy birthday my cluster! Today is the 1st anniversary of my #kubernetes cluster. Any gifts are welcome lol pic.twitter.com/xM5J0G4O3B
— Yuanying (@yuanying) 2018年10月10日
最初の投稿では運用し始めたクラスターのバージョンは伺い知れぬが、 Twitter 上の最初のアップグレードのつぶやきが、v1.7 -> v1.8 であったので、 v1.7 のいくつかだったのであろう。
そんなこんなで、今日、v1.11.2 だったクラスターを v1.12.1 にアップグレードした。 かれこれ 5 マイナーバージョンのアップグレードである。
以下、今回のアップグレードでやったこと。
apiserver の修正
--insecure-port
のフラグが (v1.11からだが) deprecated になったのに合わせて削除。
controller-manager の修正
Changelog の Known Issues に書いてあって なんじゃこりゃ、と思っていた、
kube-controller-manager currently needs a writable --cert-dir (default is /var/run/kubernetes) for generating self-signed certificates, when no --tls-cert-file or --tls-private-key-file are provided.
に思いっきり当たる。
そもそも、v1.12 から controller-manager が公開している、metrics 取得のための API が、 secure になった、というか TLS 接続がデフォルトになったのだが、 (それに合わせて色々フラグが増えているのだけれども、一見見るとなんじゃこれと思う) そのための証明書や鍵を設定していないと自己署名証明書を所定のディレクトリに自動生成してしまう、というのがこの issue。
一見すると特になんの問題もなさそうなのだが、どうやら hyperkube のイメージでは、 その「所定のディレクトリ」が read only であるらしく、 自動生成することができずに controller-manager の起動に失敗してしまうのだ!
回避方法は、一番真っ当な解決策として、「妥当な証明書をちゃんと設定してやる」というものが挙げられるが、 今の所、特に controller-manager のメトリクスは収集してないので、適当な empty dir をマウントして逃げた。 (こんな感じ)
そもそも自己署名の証明書をディスクに書き出す必要もなく、メモリに持てばいいじゃない、 などの議論がされている模様。
etcd を v3.2.18 から v3.2.24 へ
一応、ミニマムな推奨バージョンは 3.2.10 とのことだが、 v1.12 におけるデフォルトの etcd version が v3.2.24 になったことに合わせて、 etcd のバージョンを初めて上げた。
と言っても、etcd 自体は static pod で起動しているので、 やったことはマニフェストのバージョンを上げて、一台ずつ手でマニフェストを交換してやっただけ。 すんなり動いた。(めんどくさかったのでバックアップすら取っていない。)
checkpointer のバージョンアップ
self-hosted k8s をやってる人じゃないと関係ないけど、 checkpointer のバージョンを 018007e77ccd61e8e59b7e15d7fc5e318a5a2682 に上げた。 上げないとクラスター再起動が失敗する模様。
なんか、checkpointer は k8s のバージョンごとに上げないとダメな感じよね。
以上。
CoreDNS のバージョンは後で上げる。