Managed Kubernetes Cluster customizations

Deploy modifications needed while running a Kubernetes managed service.

If you have chosen to go with a managed Kubernetes Service like GKE or AKS, then as part of the managed solution you will get a CNI (Container Networking Interface) plugin deployed. Fury Kubernetes Distribution deploys Calico as its default CNI, so you will need to disable it to avoid a conflict between the two plugins.

In addition to the CNI, in a managed Kubernetes Cluster, the control-plane is also deployed by your provider. The control-plane metrics exported by each provider are different, so we must adapt how we query the Kubernetes control-plane metrics for each one.

Disable default Kubernetes Fury Distribution CNI

Setup

You will need to modify a couple of files to disable the default CNI.

$ ls Furyfile.yml
Furyfile.yml
$ ls manifests/distribution/kustomization.yaml
manifests/distribution/kustomization.yaml

Furyfile.yml

You have to remove the Calico package in this file to avoid downloading it in the future:

$ grep networking Furyfile.yml
  networking: v1.0.0
  - name: networking/calico
$ sed -i '/networking/Id' Furyfile.yml
# Optional. Delete networking module from vendor
$ rm -rf vendor/katalog/networking

kustomization.yaml

To disable the deployment of the Kubernetes Fury Distribution CNI plugin, you should Remove the CNI component in the manifestes/distribution/kustomization.yaml file.

$ grep networking manifests/distribution/kustomization.yaml
  - ../../vendor/katalog/networking/calico
$ sed -i '/networking/Id' manifests/distribution/kustomization.yaml

This way we ensure the default CNI is not deployed within the Kubernetes Fury Distribution default package.

Service Monitors (Monitoring control-plane components)

Kubernetes Fury Distribution includes resources (ServiceMonitors and Services) to enable Kubernetes control-plane components monitoring out of the box. Managed Kubernetes Services provides its control-plane components and the required resources to enable the monitoring in these services are slightly different.

Setup

You will need to modify a couple of files to enable monitoring in this kind of Kubernetes Cluster.

$ ls Furyfile.yml
Furyfile.yml
$ ls manifests/distribution/kustomization.yaml
manifests/distribution/kustomization.yaml

Furyfile.yml

You have to switch from monitoring/kubeadm-sm package to one of the Managed Kubernetes provider:

  • monitoring/gke-sm: Choose this package if you are using Google Kubernetes Engine.
  • monitoring/aks-sm: Choose this package if you are using Azure Kubernetes Service.

Let's use gke as an example:

$ sed -i .backup 's@monitoring/kubeadm-sm@monitoring/gke-sm@g' Furyfile.yml
$ cat Furyfile.yml | grep gke
  - name: monitoring/gke-sm

Then proceed to download the package in the vendor directory:

$ furyctl vendor -H
$ ls -lrt vendor/katalog/monitoring/gke-sm/
total 32
-rw-r--r--  1 sighup  staff  652 31 mar 13:33 README.md
-rw-r--r--  1 sighup  staff  535 31 mar 13:33 apiserver.yml
-rw-r--r--  1 sighup  staff  572 31 mar 13:33 kubelet.yml
-rw-r--r--  1 sighup  staff   65 31 mar 13:33 kustomization.yaml
# Optional. Delete kubeadm-sm package from vendor
$ rm -rf vendor/katalog/monitoring/kubeadm-sm/

kustomization.yaml

Once the new package is present in the vendor directory, you have to modify the manifests/distribution/kustomization.yaml to change the monitoring package from kubeadm to gke or aks:

To be consistent with the previous example, let's continue assuming we are deploying to gke:

$ sed -i .backup 's@monitoring/kubeadm-sm@monitoring/gke-sm@g' manifests/distribution/kustomization.yaml
$ grep "gke-sm" manifests/distribution/kustomization.yaml
  - ../../vendor/katalog/monitoring/gke-sm

Test

If you have followed these steps, you can verify everything is working with the following command:

$ kustomize build manifests