Kubernetes cheat sheet

This is a list of useful information regarding Kubernetes that the GitLab Support Team sometimes uses while troubleshooting. GitLab is making this public, so that anyone can make use of the Support team’s collected knowledge

caution
These commands can alter or break your Kubernetes components so use these at your own risk.

If you are on a paid tier and are not sure how to use these commands, it is best to contact Support and they will assist you with any issues you are having.

Generic Kubernetes commands

  • How to authorize to your GCP project (can be especially useful if you have projects under different GCP accounts):

    gcloud auth login

  • How to access Kubernetes dashboard:

    # for minikube:
minikube dashboard —url
# for non-local installations if access via Kubectl is configured:
kubectl proxy

  • How to SSH to a Kubernetes node and enter the container as root https://github.com/kubernetes/kubernetes/issues/30656:

    • For GCP, you may find the node name and run gcloud compute ssh node-name.
    • List containers using docker ps.
    • Enter container using docker exec --user root -ti container-id bash.

  • How to copy a file from local machine to a pod:

    kubectl cp file-name pod-name:./destination-path

  • What to do with pods in CrashLoopBackoff status:

    • Check logs via Kubernetes dashboard.

    • Check logs via Kubectl:

      kubectl logs <webservice pod> -c dependencies

  • How to tail all Kubernetes cluster events in real time:

    kubectl get events -w --all-namespaces

  • How to get logs of the previously terminated pod instance:

    kubectl logs <pod-name> --previous

    No logs are kept in the containers/pods themselves. Everything is written to stdout. This is the principle of Kubernetes, read Twelve-factor app for details.

  • How to get cron jobs configured on a cluster

    kubectl get cronjobs

    When one configures cron-based backups, you will be able to see the new schedule here. Some details about the schedules can be found in Running Automated Tasks with a CronJob

GitLab-specific Kubernetes information

  • Minimal configuration that can be used to test a Kubernetes Helm chart.

  • Tailing logs of a separate pod. An example for a webservice pod:

    kubectl logs gitlab-webservice-54fbf6698b-hpckq -c webservice

  • Tail and follow all pods that share a label (in this case, webservice):

    # all containers in the webservice pods
kubectl logs -f -l app=webservice --all-containers=true --max-log-requests=50

# only the webservice containers in all webservice pods
kubectl logs -f -l app=webservice -c webservice --max-log-requests=50

  • One can stream logs from all containers at once, similar to the command gitlab-ctl tail in a Linux package installation:

    kubectl logs -f -l release=gitlab --all-containers=true --max-log-requests=100

  • Check all events in the gitlab namespace (the namespace name can be different if you specified a different one when deploying the Helm chart):

    kubectl get events -w --namespace=gitlab

  • Most of the useful GitLab tools (console, Rake tasks, etc) are found in the toolbox pod. You may enter it and run commands inside or run them from the outside.

    note
    The task-runner pod was renamed to toolbox in GitLab 14.2 (charts 5.2).
    # find the pod
kubectl --namespace gitlab get pods -lapp=toolbox

# enter it
kubectl exec -it <toolbox-pod-name> -- bash

# open rails console
# rails console can be also called from other GitLab pods
/srv/gitlab/bin/rails console

# source-style commands should also work
cd /srv/gitlab && bundle exec rake gitlab:check RAILS_ENV=production

# run GitLab check. The output can be confusing and invalid because of the specific structure of GitLab installed via helm chart
/usr/local/bin/gitlab-rake gitlab:check

# open console without entering pod
kubectl exec -it <toolbox-pod-name> -- /srv/gitlab/bin/rails console

# check the status of DB migrations
kubectl exec -it <toolbox-pod-name> -- /usr/local/bin/gitlab-rake db:migrate:status

    You can also use gitlab-rake, instead of /usr/local/bin/gitlab-rake.

  • Troubleshooting Infrastructure > Kubernetes clusters integration:

    • Check the output of kubectl get events -w --all-namespaces.
    • Check the logs of pods within gitlab-managed-apps namespace.
    • On the side of GitLab check Sidekiq log and Kubernetes log. When GitLab is installed via Helm chart, kubernetes.log can be found inside the Sidekiq pod.

  • How to get your initial administrator password https://docs.gitlab.com/charts/installation/deployment.html#initial-login:

    # find the name of the secret containing the password
kubectl get secrets | grep initial-root
# decode it
kubectl get secret <secret-name> -ojsonpath={.data.password} | base64 --decode ; echo

  • How to connect to a GitLab PostgreSQL database.

    note
    The task-runner pod was renamed to toolbox in GitLab 14.2 (charts 5.2).

    In GitLab 14.2 (chart 5.2) and later:

    kubectl exec -it <toolbox-pod-name> -- /srv/gitlab/bin/rails dbconsole --include-password --database main

    In GitLab 14.1 (chart 5.1) and earlier:

    kubectl exec -it <task-runner-pod-name> -- /srv/gitlab/bin/rails dbconsole --include-password

  • How to get information about Helm installation status:

    helm status name-of-installation

  • How to update GitLab installed using Helm chart:

    helm repo update

# get current values and redirect them to yaml file (analogue of gitlab.rb values)
helm get values <release name> > gitlab.yaml

# run upgrade itself
helm upgrade <release name> <chart path> -f gitlab.yaml

    See also Updating GitLab by using the Helm chart.

  • How to apply changes to GitLab configuration:

    • Modify the gitlab.yaml file.

    • Run the following command to apply changes:

      helm upgrade <release name> <chart path> -f gitlab.yaml

  • How to get the manifest for a release. It can be useful because it contains the information about all Kubernetes resources and dependent charts:

    helm get manifest <release name>

Installation of minimal GitLab configuration via minikube on macOS

This section is based on Developing for Kubernetes with minikube and Helm. Refer to those documents for details.

  • Install Kubectl via Homebrew:

    brew install kubernetes-cli

  • Install minikube via Homebrew:

    brew cask install minikube

  • Start minikube and configure it. If minikube cannot start, try running minikube delete && minikube start and repeat the steps:

    minikube start --cpus 3 --memory 8192 # minimum amount for GitLab to work
minikube addons enable ingress

  • Install Helm via Homebrew and initialize it:

    brew install helm

  • Copy the minikube minimum values YAML file to your workstation:

    curl --output values.yaml "https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml"

  • Find the IP address in the output of minikube ip and update the YAML file with this IP address.

  • Install the GitLab Helm chart:

    helm repo add gitlab https://charts.gitlab.io
helm install gitlab -f <path-to-yaml-file> gitlab/gitlab

    If you want to modify some GitLab settings, you can use the above-mentioned configuration as a base and create your own YAML file.

  • Monitor the installation progress via helm status gitlab and minikube dashboard. The installation could take up to 20-30 minutes depending on the amount of resources on your workstation.

  • When all the pods show either a Running or Completed status, get the GitLab password as described in Initial login, and log in to GitLab via the UI. It will be accessible via https://gitlab.domain where domain is the value provided in the YAML file.

Patching the Rails code in the toolbox pod

caution
This task is not something that should be regularly performed. Use it at your own risk.

Patching operational GitLab service pods requires building new images, with the modified source code inside. These can not be directly patched. The toolbox / task-runner pod has everything needed to operate as a Rails-based pod, without interfering with other normal service operations. You can use it to run independent tasks, and to modify the source code temporarily to perform some tasks.

note
If you make any changes using the toolbox pod, those will not be persisted if the pod is restarted. They’re only present for the life of the container’s operation.

To patch the source code in the toolbox pod:

  1. Fetch the desired .patch file to be applied:

    • Either download the diff of a merge request directly as a patch file.

    • Or, fetch the diff directly using curl. Replace <mr_iid> below with the IID of the merge request, or change the URL to point to a raw snippet:

      curl --output ~/<mr_iid>.patch "https://gitlab.com/gitlab-org/gitlab/-/merge_requests/<mr_iid>.patch"

  2. Patch the local files on the toolbox pod:

     cd /srv/gitlab
 busybox patch -p1 -f < ~/<mr_iid>.patch