Get started with Kubectl to manage Kubernetes clusters – CloudSavvy IT

Kubernetes is a container organization engine that enables you to deploy container workloads in a scalable way. The official command line tool, kubectl, gives control over your clusters and the resources within.

Install Kubectl

kubectl is supported on Linux, macOS and Windows. Different distribution formats are offered depending on the platform. Pre-compiled binaries are produced for all supported operating systems and made available through direct download links.

You will also find kubectl within the package managers of Snap, Homebrew, Chocolatey and Scoop. It can be installed via apt and yum by adding the Google Cloud repository to your system. And last but not least, kubectl also comes with the Google Cloud SDK ̵

1; if you already have it installed, launch gcloud components install kubectl to download the tool.

To see the options available for your system, refer to the official installation guide. Installation steps can change over time so check the documentation before reinstalling kubectl

Configuration

The configuration is saved in the .kube directory in your home folder. The default configuration file is ~/.kube/config

You can add additional files to this folder. They will be merged together in the final configuration used at runtime. If you want to use a specific configuration file or another set of files, you must use the --kubeconfig flag or the KUBECONFIG environment variable.

kubectl --kubeconfig=/example/file get pods
# OR
KUBECONFIG=/example/file kubectl get pods

All paths written in configuration files are resolved in relation to the file’s own location. Paths passed to command line flags are resolved in relation to your workbook. You can view the final configuration that will be used by kubectl run through kubectl config view

Command line flags are supported for some settings. This allows you to overwrite your configuration files. Available flags include --server (cluster URL), --username (username to connect as), --password --token (API token) and --namespace (select the cluster namespace you want to communicate with).

Contexts

Within configuration files you can define multiple “contexts”. Allows you to group commonly used “access parameters”, such as cluster URL and user accounts, under a named credential.

Use. To configure settings by context kubectl config set-context my-context --cluster=my-app --namespace=productionThis example would create a new context with the name my-context that defines the default settings for the Kubernetes cluster and namespace to work with.

Contexts are applied with the kubectl config use-context my-context order. Any further invocation of kubectl would be the parameters of the my-context context, so you are connected to the my-app cluster in the production namespace.

Effective use of contexts simplifies interaction with kubectlWithout these files, you will have to manually create unique configuration files that will be toggled using the KUBECONFIG flag or environment variable.

Interact with your cluster

Most kubectl commands use the same basic format:

kubectl command type name

The command is the operation you want to perform – usually create get describe or deleteThe type is the kind of tool you will be communicating with, such as pod or deploymentYou can use the singular or the plural.

The name component must be the name of the resource you are referencing. You can enter multiple names separated by spaces to get output in bulk. It is also possible to use the -f flag to specify the path to a JSON or YAML file containing a list of resource names.

Here are some sample commands, all of which work against the currently selected context:

• kubectl get pods – Get the details of all your pods
• kubectl get pod my-pod – Get the details of the recalled pod my-pod
• kubectl get pod my-pod another-pod – Get the details of the mentioned pods my-pod and another-pod
• kubectl get pod/my-pod deployment/my-deployment – Get the details of the recalled pod my-pod and the stakes called my-deployment – this syntax variation allows you to get multiple resource types with one command
• kubectl delete pod my-pod – Delete the recalled pod my-pod
• kubectl logs my-pod – Get log output from it my-pod below
• kubectl apply -f ./manifest.yml – Apply a patch to your cluster from the Kubernetes manifest stored in manifest.yml

Commands are available for all resource types offered by your Kubernetes cluster. This even extends to custom resource definitions; they integrate with the Kubernetes API and get their own RESTful endpoints kubectl has access.

A complete kubectl command reference is available in the Kubernetes documentation. There is also a cheat sheet with commonly used commands when working with typical resource types.

Output formats

The output is usually sent as a formatted list or table. This displays information in a human-readable style that you can quickly scroll through.

Several alternative output options are available. You can switch to a different formatter with the -o (or --output) flag.

The json output style displays the JSON representation of the Kubernetes API resource that you have access to. Likewise yaml gives you the data from the source as a YAML representation.

When using the human readable style, you can specify the table columns using the custom-columns style. Specify a comma separated list of column name and value reference pairs:

kubectl get pods -o custom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace

This would display the name and namespace of each pod in columns labeled NAME and NAMESPACE respectively. Instead of writing columns inline in your command, you can define them in a file and pass them to --custom-columns-file

There is built-in support for sorting output by the value of a particular field. Use --sort-by, passing the reference of the field:

kubectl get pods --sort-by=.metadata.name

Sorting supports JSONPath expressions. These can also be used to build filtered queries using the jsonpath formatter. JSONPath is a query language for JSON objects that allows you to manipulate Kubernetes API queries more directly in kubectl

Use within scripts

kubectl is intended for both direct human interaction and programmatic invocation via scripts. There are some best practices to follow when creating scripts kubectl to ensure predictable output.

Fully qualify references to resource types so that they are pinned to a particular version, e.g. pods.v1.core/my-job instead of pods my-jobThis minimizes the risk of Kubernetes updates breaking your script.

The access configuration must be passed directly from your script to kubectlso that you are not dependent on the outside environment. This further reduces the risk of breakage as a result kubectl updates – functions like contexts can change over time, while the core command line arguments are less likely to change.

Finally, make sure to disable human readable output and use the JSON or YAML formatter instead. This gives your scripting machine-oriented data to work with, so you don’t have to parse tables yourself.

Conclusion

kubectl is the go-to solution for managing a Kubernetes cluster. It is a comprehensive tool with full support for the platform’s capabilities.

The broad functionality makes for a long list of commands, but the clear separation between action type, resource type, and resource name helps keep usage simple and memorable. When in doubt, you can install shell autocompletion to help you find a suitable command.