kubectl

GKE: Determine Anthos on-prem GKE master node and IP address

If you are using Anthos GKE on-premise and need to determine which node of your Admin Cluster is the master, query for the master role.  The label is ‘node-role.kubernetes.io/master’. $ kubectl get nodes -l node-role.kubernetes.io/master NAME STATUS ROLES AGE VERSION gke-admin-master-adfwa Ready control-plane,master 7d v1.24.9-gke.100 # using wide will also show External and Internal IP GKE: Determine Anthos on-prem GKE master node and IP address

Kubernetes: patch every array element using kubectl and jq

Below is an example using ‘kubectl patch’ to update the securityContext of a single, specific container named ‘my-init-container1’ of the ‘initContainers’ list. kubectl patch deployment my-deployment -n default –patch='{ “spec”: { “template”: { “spec”: { “initContainers”: [ { “name”: “my-init-container1”, “securityContext”: { “runAsUser”: 999 } } ] } } } }’ But ‘initContainers’ is an Kubernetes: patch every array element using kubectl and jq

GCP: fix kubectl auth plugin deprecation warning by installing new auth plugin

Starting with Kubernetes client 1.22, you may start seeing warning messages about your authentication mechanism when running commands.  Here is an example when using gcloud for GKE cluster credentials. WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.26+; use gcloud instead. This is because the authentication provider-specific login code will be removed GCP: fix kubectl auth plugin deprecation warning by installing new auth plugin

Kubernetes: copying files into and out of containers without ‘kubectl cp’

The ‘kubectl cp‘ command is a convenient way to get files into and out of remote containers, however it requires that the ‘tar’ utility be installed inside the container. There are many images that have removed this utility because of the identified security vulnerability, while others have removed it due to the adoption of the Kubernetes: copying files into and out of containers without ‘kubectl cp’

Kubernetes: kustomize overlay to enrich a base resource

With kustomize built into the kubectl CLI since version 1.14, there is little reason not to take advantage of this overlay system to deploy components to your Kubernetes cluster. Kustomize has the advantage that it is purpose built to understand and validate yaml and Kubernetes CRD, as opposed to bespoke templating solutions using sed/envsubst, Ansible, Kubernetes: kustomize overlay to enrich a base resource

Kubernetes: emptying the finalizers for a namespace that will not delete

If your intent is to delete all the objects in a namespace, but the command is not completing, emptying the namespace finalizer will often allow the deletion to finish. For example, if you have tried deleting the “my-namespace” like below and it will not complete. kubectl delete ns my-namespace –force –grace-period=0 Then as written by Kubernetes: emptying the finalizers for a namespace that will not delete

Kubernetes: using kubectl to wait for condition of pods, deployments, services

Instead of deploying a pod or service and periodically checking its status for readiness, or having your automation scripts wait for a certain number of seconds before moving to the next operation, it is much cleaner to use ‘kubectl wait’ to sense completion. Wait for pod Here is how you would wait for READY status Kubernetes: using kubectl to wait for condition of pods, deployments, services

Kubernetes: pulling out the ready status of individual containers using kubectl

kubectl will give you a sythesized column showing how many container instances in a pod are READY with the default ‘get pods’ command.  But if you are dealing with json output and need this information, then you can extract it using jsonpath or jq. Here is an example output from ‘get pods’ showing the READY Kubernetes: pulling out the ready status of individual containers using kubectl

Kubernetes: adding and removing pod template annotations using kubectl

Although ‘kubectl annotate‘ will set an annotation on a  object directly, it will not set the annotation on the more deeply nested pod template for a Deployment or Daemonset. If you want to quickly set the annotation on a pod template (.spec.template.metadata.annotations) without modifying the full manifest, you can  use the ‘patch‘ command.  As a Kubernetes: adding and removing pod template annotations using kubectl

Kubernetes: Updating an existing ConfigMap using kubectl replace

Creating a ConfigMap using ‘kubectl create configmap’ is a straightforward operation.   However, there is not a corresponding ‘kubectl apply’ that can easily update that ConfigMap. As an example, here are the commands for the creation of a simple ConfigMap using a file named “ConfigMap-test1.yaml“. $ cat ConfigMap-test1.yaml test1: foo: bar # create and then show Kubernetes: Updating an existing ConfigMap using kubectl replace

Kubernetes: running Minikube locally on Ubuntu using VirtualBox

Updated article to latest Minikube, Feb 2019 Minikube is a tool that runs a Kubernetes stack inside a single VM being run by a local virtualization engine such as VirtualBox.  This makes it ideal for local development and experimentation. In this article we’ll be going through installation and validation of a Minikube installation on Ubuntu Kubernetes: running Minikube locally on Ubuntu using VirtualBox