Grafana blank graphs in dashboards after update

Upgrading Grafana (kube-prometheus-stack) from version 23.1 to the latest one currently 44.2.1 results in many Grafana graphs to disappear from the existing dashboards.

Since editing the actual graphs and trying to use ‘Run queries’ does not seem to work, a work around is the following:

  • Edit the blank graph.
  • Add a new query (B) – even empty is fine
  • Use the ‘Run queries’ (it does not matter if you use the button on the original one or in the new query B)
  • Delete the new query B
  • The graph should appear again, so use the ‘Apply’ button on top right.
  • Repeat the process for any additional graphs in the dashboard
  • When you finish ‘Save’ the dashboard
  • The dashboard should be working again

PostgreSQL connection string for Percona PostgreSQL K8S operator

Since the documentation does not contain any information about how you can connect an existing application to the newly created percona pgo cluster, you can use something like the following in your pod postgresql connection string.

postgresql://username:password@cluster1.pgo-perc-production.svc.cluster.local/production

where cluster1.pgo-perc-production.svc.cluster.local points to your newly created cluster and the /production is the database to connect to.

googlecloudsdk.calliope.exceptions.HttpException: ResponseError: code=400, message=Autopilot clusters must be regional clusters.

Problem

Trying to create an auto-cluster either using terraform or gcloud cli, and specifying the region name returns the error that ‘Autopilot clusters must be regional clusters.

So with gcloud this is the command and output

kosmas: (master %)$ gcloud container clusters create-auto test-cluster --region=europe-west6-b
Note: The Pod address range limits the maximum size of the cluster. Please refer to https://cloud.google.com/kubernetes-engine/docs/how-to/flexible-pod-cidr to learn how to optimize IP address allocation.
ERROR: (gcloud.container.clusters.create-auto) ResponseError: code=400, message=Autopilot clusters must be regional clusters.

Solution

Using the actual region name (that can be taken from the list of available zones/regions)

gcloud compute zones list

NAME                       REGION                   STATUS  NEXT_MAINTENANCE  TURNDOWN_DATE
us-east1-b                 us-east1                 UP
us-east1-c                 us-east1                 UP
...
europe-west6-b             europe-west6             UP
...

And using the correct region name (without the b)

gcloud container clusters create-auto test-cluster --region=europe-west6 --verbosity debug

...
Created [https://container.googleapis.com/v1/projects/gitlab-runner-343714/zones/europe-west6/clusters/test-cluster].
...
NAME          LOCATION      MASTER_VERSION   MASTER_IP     MACHINE_TYPE  NODE_VERSION     NUM_NODES  STATUS
test-cluster  europe-west6  1.21.6-gke.1503  xxx.xxx.xxx.xxx  e2-medium     1.21.6-gke.1503  3          RUNNING

Kubectl using -l a=something -l b=other or -l a=something,b=other

When you have two pods with different labels, let’s say one with two labels a=something and b=other, and the second one with label b=other, when you use kubectl to get them there is a difference in the way that the -l selector is used.

So using kubectl -n namespace get pods -l a=something -l b=other it will give you back both pods as it works as an OR operator.

If you wanted to get only the first one that has both labels, but not the second, you would need to use it as in kubectl -n namespace get pods -l a=something,b=other.

In other words the comma separator acts as a logical AND operator in selecting the labels.

Get/Set platform information

To get or set in environment variables the platform information of a system you can use the following:

export ARCH=$(case $(arch) in x86_64) echo -n amd64 ;; aarch64) echo -n arm64 ;; *) echo -n $(arch) ;; esac)
export OS=$(uname | awk '{print tolower($0)}')

Taken from the installation instructions of the Operator SKD here: https://master.sdk.operatorframework.io/docs/installation/

sudo kubeadmin init returns with: [ERROR Swap]: running with swap on is not supported. Please disable swap

Problem

You are trying to set up kubernetes on your local machine but trying to use initialize it with kubeadmin init, returns the following error:

[init] Using Kubernetes version: v1.18.3
[preflight] Running pre-flight checks
error execution phase preflight: [preflight] Some fatal errors occurred:
        [ERROR Swap]: running with swap on is not supported. Please disable swap
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
To see the stack trace of this error execute with --v=5 or higher

Solution

Switch the swap to off (Ubuntu command below) and try again.

sudo swapoff -a

WARN[0000] Your Skaffold version might be too old. Download the latest version (1.0.1) at https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64

Problem

You would like to follow the example for working with skaffold by using the skaffold dev command but you are getting the following error:

kosmas:getting-started (master)$ skaffold dev
WARN[0000] Your Skaffold version might be too old. Download the latest version (1.0.1) at https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64 

Solution

Download the latest release from here https://github.com/GoogleContainerTools/skaffold/releases and follow the instructions for installing it in your system (ie linux):

 curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/v1.0.1/skaffold-linux-amd64 && chmod +x skaffold && sudo mv skaffold /usr/local/bin

kubectl error: “The connection to the server localhost:8080 was refused – did you specify the right host or port?”

Problem

You want to use the kubectl to get your cluster information but you are getting the following error message

$ kubectl cluster-info
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
The connection to the server localhost:8080 was refused - did you specify the right host or port?

Solution

That could happen if you have already setup kubectl before or have used a different environment.

So you will need to first unset the environment variable KUBECONFIG with:

$ unset KUBECONFIG

and then use the gcloud client to set your environment again:


$ gcloud container clusters get-credentials your_cluster_name --zone europe-west2-a --project your_project_name

So after this you should be able to use kubectl to get the cluster information

kubeconfig entry generated for your_cluster_name.

$ kubectl cluster-info
Kubernetes master is running at https://xxx.xxx.xxx.xxx
GLBCDefaultBackend is running at https://xxx.xxx.xxx.xxx/api/v1/namespaces/kube-system/services/default-http-backend:http/proxy
Heapster is running at https://xxx.xxx.xxx.xxx/api/v1/namespaces/kube-system/services/heapster/proxy
KubeDNS is running at https://xxx.xxx.xxx.xxx/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://xxx.xxx.xxx.xxx/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy