Google Cloud lets you run Kubernetes in three flavors:

• Vanilla is when you do all on your own. This is also the quickest “lift and shift” strategy to migrate your cluster to cloud. Essentially it is just a group of virtual machines that run on Google Compute Engine (GCE).
• Managed that shifts administration and maintenance tasks from DevOps teams to the cloud service. See Google Kubernetes Engine (GKE) Standard cluster architecture and Autopilot for more details.
• Knative, that is sometimes referred to as cloud native, which hides control plane and other infrastructure details behind the familiar interface of workload launching. Cloud Run offers running service and job workloads using the GKE platform behind the Knative interface.

Many DevOps teams prefer the managed flavor to enjoy a balance between carefree administration and the level of control that is very close to vanilla Kubernetes. Comparing GKE Autopilot and Standard, many prefer Standard due to higher control granularity over node management, security and version configuration and other options. In the cluster observability domain, these differences are less distinctive since both come with a rich set of monitoring and logging capabilities including control plane metrics.

You may have seen this notice when opening SLOs Overview in Cloud Console.

This notice announces a recent change in the way of defining services for Cloud Monitoring. Before the change, Cloud Monitoring automatically discovered services that were provisioned in AppEngine, Cloud Run or GKE. These services were automatically populated in the Services Overview dashboard. After the change, all services in the Services Overview dashboard have to be created explicitly. To simplify this task, when defining a new service in UI you are presented with a list of candidates that is built based on the auto-discovered services. The full list of the auto-discovered services includes managed services from AppEngine, Cloud Run and Istio as well as GKE workloads and services. Besides UI you can add managed services to Cloud Monitoring using the services.create API or using the Terraform google_monitoring_service resource.

Google Cloud supports service monitoring by defining and tracking SLO of the services based on their metrics that are ingested to Google Cloud. This support greatly simplifies implementing SRE practices for services that are deployed to Google Cloud or that store telemetry data there. To make it even more simple to developers, the service monitoring is able to automatically detect many types of managed services and supports predefined availability and latency SLI definitions for them.
When you define a new SLO you are prompted to select a predefined SLI or to define your own.

I wanted to introduce a support for “series” ‒ an ordered collection of posts about the same topic. For example, this post is the 4th post in the series “Getting Started with Hugo”. And I wanted to enable navigation between different posts from the same series instead of just going to “next” or “previous” post in the blog. I looked on internet and found many articles about how to do it using Hugo. The posts that I found used older versions of Hugo because of configuration parameters and methodology that they used. I learned from these posts and came with my own implementation.

Hosting

After a brief review of the selected Hugo settings, let’s review the decisions about hosting. I used only two criteria when I was choosing hosting for my blog website:

• Convenience – the service should be simple to use, allow automation, to have both CLI and Web interface and, ideally, familiar
• Costs – it should be cheap or, ideally, it should be free

The choice for the website source code management was straightforward. Github answers both criteria. It is simple. Supports automations via workflows and actions. And I work with it everyday. Needless to say that it is free (for now).

Almost all customizations for Hugo websites can be done using configuration. The configuration is stored in the single place the hugo.yaml file at the root folder of the website. Hugo comes with the hugo.toml (TOML) but I prefer to use YAML for my configurations. Hugo also supports JSON if you like it more.

Documentation is nice and descriptive. I found several guidelines about what should be included into the config file. The following is my experience with the configuration, a couple of “learned lessons” and the list of settings I found useful. While I write it here in some creative chaotic order, in the file I ordered all of them alphabetically so it is easy for me to find if I just scroll through.

I often (re-)use the same laptop to work in different projects that have to be committed to Github under different identities. By “identities” I do not mean different Github accounts. I sign my commits with SSH key registered at Github to emails that are associated with my Github account. Different types of projects are supposed to sign with different emails and keys. I could call git config... each time or maintain multiple .gitconfig files in different directories. However, there is more effective way IMHO. The way is to use includeif setting of the Git configuration. This is how it works.

Welcome, this is the first post in my new blog. I found only two reasons for doing self-hosted blog:

1. I can select the engine and formatting instead of getting annoyed with limitations of managed (although free) platforms such as Medium.
2. Controlling blog hosting makes it more resilient compared to external hosting that is driven by business dedcisions over which I have no control.

So, I decided to do an experiment with creating a blog website and in a year (it will be March, 2025) to run a retrospective of the blog hosting and maintenance and decide whether I will continue with the project. Until then I will mirror most of the materials to my blog on Medium.