Kubernetes on Kenno's Open Note

ArgoCD CLI failed to invoke grpc call

Tue, 11 Mar 2025 20:24:00 +1100

When running argocd CLI, the following warning message shown:

➜ argocd app list
WARN[0000] Failed to invoke grpc call. Use flag --grpc-web in grpc calls. To avoid this warning message, use flag --grpc-web.
NAME  CLUSTER  NAMESPACE  PROJECT  STATUS  HEALTH  SYNCPOLICY  CONDITIONS  REPO  PATH  TARGET

To suppress this warning message, re-run the login with --grpc-web option. For example:

➜ argocd login argocd.apps.tuaf.local.cluster --grpc-web
Username: admin
Password:
'admin:login' logged in successfully
Context 'argocd.apps.tuaf.local.cluster' updated

➜ argocd app list
NAME  CLUSTER  NAMESPACE  PROJECT  STATUS  HEALTH  SYNCPOLICY  CONDITIONS  REPO  PATH  TARGET

Reference:

Setting Retention for Kube Prometheus Stack

Tue, 25 Feb 2025 10:42:41 +1100

When deploying the prometheus-community/kube-prometheus-stack in a k8s cluster, the default retention for Prometheus scrapped data is 10d at the time of this writing or Helm chart kube-prometheus-stack-69.4.1. As a result, the longhorn storage is filled up fast, and caused the Prometheus to crash.

So I’d decided to change the retention period to 3 days, and also set retention size to 4GB. To do this, update the values file for the Helm chart with the following values:

Upgrading Longhorn with Helm

Fri, 23 Aug 2024 13:55:07 +1000

For my test Kubernetes cluster, Longhorn is used as the persistent block storage. The installed version is 1.6.2, and the version 1.7.0 is available now. So today, I’m going to share how to perform the Longhorn upgrade using Helm.

I’m going to try to do this live as usual. Of course, I already created snapshots for all my K8s nodes in case thing goes south.

First, let’s verify the current installed version of Longhorn [1].

Deploy metrics-server in Kubernetes using Helm

Wed, 24 Apr 2024 01:20:00 +1000

This is a short note on how to install metrics-server using Helm on my k8s cluster.

$ kubectl version
Client Version: v1.29.3
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.3

$ helm version --short
v3.14.4+g81c902a

Before we can install the chart, we will need to add the metrics-server repo to Helm.

$ helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/

Update the repo:

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "metrics-server" chart repository
Update Complete. ⎈Happy Helming!⎈

I also need to make a small customization to the chart’s default value since my k8s cluster uses self-signed certificates.

How to deploy Uptime Kuma on kubernetes

Fri, 15 Mar 2024 18:39:02 +1100

I’ve been running Uptime Kuma on a podman-container for a long time with no problem. Recently, though, I’ve been running a mini Kubernetes cluster at home, and decided to move this conatainer to the same cluster.

The following is to document how I deploy Uptime Kuma on a Kubernetes cluster.

As I’m new to Kubernetes world, I broke down the tasks I need to do in 6 pieces:

$ ls -1
1.namespace.yaml
2.service.yaml
3.pvc.yaml
4.deployment.yaml
5.tls-secret.yaml
6.ingress.yaml

The first step is to create a new namespace for this application or deployment. It’ll be called ‘uptime-kuma’.

$ cat 1.namespace.yaml
kind: Namespace
apiVersion: v1
metadata:
  name: uptime-kuma

$ kubectl apply -f ./1.namespace.yaml

Create a new service, which will listen on port 3001.

$ cat 2.service.yaml
apiVersion: v1
kind: Service
metadata:
  name: uptime-kuma-svc
  namespace: uptime-kuma
spec:
  selector:
    app: uptime-kuma
  ports:
  - name: uptime-kuma
    port: 3001
    targetPort: 3001
    protocol: TCP

Next is to create a persistent volume claim for Uptime Kuma’s app data. Based on the current usage on my existing podman-container, 512 MiB is plenty. In my cluster, I use Longhorn as the persistent block storage.

$ cat 3.pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: uptime-kuma-pvc
  namespace: uptime-kuma
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 512Mi

Here is the deployment file.

$ cat 4.deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: uptime-kuma
  namespace: uptime-kuma
spec:
  selector:
    matchLabels:
      app: uptime-kuma
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: uptime-kuma
    spec:
      containers:
      - name: uptime-kuma
        image: louislam/uptime-kuma:1.23.11
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 3001
          name: web-ui
        resources:
          limits:
            cpu: 200m
            memory: 512Mi
          requests:
            cpu: 50m
            memory: 128Mi
        livenessProbe:
          tcpSocket:
            port: web-ui
          initialDelaySeconds: 60
          periodSeconds: 10
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /
            port: web-ui
          initialDelaySeconds: 30
          periodSeconds: 10
        volumeMounts:
        - name: data
          mountPath: /app/data
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: uptime-kuma-pvc

(Optional) I want to use SSL when accessing the web UI of Uptime Kuma, therefore I need to create a new TLS secret.

$ cat 5.tls-secret.yaml
apiVersion: v1
data:
  tls.crt: VERY-LONG-BASE-64-ENCODED-STRING
  tls.key: ANOTHER-LONG-BASE-64-ENCODED-STRING
kind: Secret
metadata:
  name: wildcard-tls-secret
  namespace: uptime-kuma
type: kubernetes.io/tls

The last file 6.ingress.yaml contains the manifest for ingress-nginx which allows me to access the Uptime Kuma at https://uptime.home-lab-internal-domain.com:

$ cat 6.ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: uptime-kuma-ingress
  namespace: uptime-kuma
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - uptime.home-lab-internal-domain.com
    secretName: wildcard-tls-secret
  rules:
  - host: uptime.home-lab-internal-domain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: uptime-kuma-svc
            port:
              number: 3001

References:

What is in a Longhorn volume?

Sun, 15 Oct 2023 18:57:07 +1100

Do you know? Well, before today, neither did I.

I’m pretty late to Kubernetes. I heard about it many hears ago, but unfortunately, I had no need to use it at home or at work. Even today, there is no workload that requires a Kubernetes cluster to run on. However, I think I can’t ignore Kubernetes any longer, and I need to learn about it now, well “better be late than never”, right?

Installing Ingress-Nginx Controller with Helm

Tue, 26 Sep 2023 22:35:22 +1000

In my previous post, I showed how to install helm CLI on a server/instance running AlmaLinux 9. Now, I will share how to use helm to install the Ingress-Nginx Controller for a Kubernetes cluster.

We install a package known as “chart” from a Helm repository. Initially, there is no repo, and can be seen below:

$ helm repo list
Error: no repositories to show

In order to install Ingress-Nginx Controller, I first need to add a new repository.

Installing HELM Cli on AlmaLinux 9

Tue, 26 Sep 2023 21:01:05 +1000

Recently, I decided to pick up learning Kubernetes again after completely being absent from this world for many years. In this post, I’ll document how to install Helm CLI on AlmaLinx 9. Helm is like a package manager for Kubernetes. Helm CLI can be installed on your local machine, it does not to be installed on the Kubenetes node. However, in order to interact with your Kubernetes cluster, you’ll need to also have kubectl command as well as properly configured it to interact with your Kubernetes cluster.