Google Kubernetes Engine

[captn3m0]

I'd thought this would be easy, but damn Google makes this confusing

Important considerations:

1. Users can pick different kinds of clusters (standard v/s autopilot)
2. autopilot clusters must pick a release channel, but standard clusters can pick a kubernetes minor version
3. standard clusters not enrolled in a release channel will still get automatic control plane upgrades. You can delay them or limit them by defining maintenance windows, but you can't stop them.
4. node upgrades are in your control only if you picked a minor version.
5. Even then, google can decide to upgrade your nodes in select cases (See last link)

Note that there are no EoL dates or active support dates for release channels since they will always be supported. Static releases do have a "release date" (when the version was made available in static), but I had to remove it to keep it consistent.

Preview: https://deploy-preview-314--endoflife-date.netlify.app/gke

Pages consulted:

• https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview
• https://cloud.google.com/kubernetes-engine/versioning
• https://cloud.google.com/kubernetes-engine/docs/release-notes
• https://cloud.google.com/kubernetes-engine/docs/release-notes-nochannel
• https://cloud.google.com/anthos/clusters/docs/security-bulletins
• https://cloud.google.com/kubernetes-engine/docs/concepts/release-channels
• https://cloud.google.com/kubernetes-engine/docs/release-schedule
• https://cloud.google.com/kubernetes-engine/upgrades

[captn3m0]

Automation Notes

Since GKE releases are quite frequent, it is very hard to keep the latest field updated regularly. Hence, I tried to automate it.

GKE has a Get Server Config API which returns the data gke.json.zip

However, the API needs authentication, so I've created a service account with zero permissions. There's 2 new scripts:

_auto/gke.rb

Authenticates to Google APIs, calls the get_server_config API and stores a parsed output in _data/gke.json

_plugins/liquify.rb

Jekyll doesn't permit YAML frontmatter to contain liquid tags. So we keep the latest tag as a liquid string, and then parse it with a liquify filter in the layout file instead.

An option, perhaps down the line would be to move the gke.json file (and corresponding code) to a separate repo, which can perhaps be fetched at build-time instead.

[BiNZGi]

I checked the details and all is okay. The icon does not render and gives a 404 on the image. Please check...

[captn3m0]

Forgot to rebase against master (icon_slug changed to iconSlug there). Should be good now

[BiNZGi]

All good now, nice work -> merge