Book Image

kubectl: Command-Line Kubernetes in a Nutshell

By : Rimantas Mocevicius
Book Image

kubectl: Command-Line Kubernetes in a Nutshell

By: Rimantas Mocevicius

Overview of this book

The kubectl command line tool lets you control Kubernetes clusters to manage nodes in the cluster and perform all types of Kubernetes operations. This introductory guide will get you up to speed with kubectl in no time. The book is divided into four parts, touching base on the installation and providing a general overview of kubectl in the first part. The second part introduces you to managing Kubernetes clusters and working with nodes. In the third part, you’ll be taken through the different ways in which you can manage Kubernetes applications, covering how to create, update, delete, view, and debug applications. The last part of the book focuses on various Kubernetes plugins and commands. You’ll get to grips with using Kustomize and discover Helm, a Kubernetes package manager. In addition to this, you’ll explore how you can use equivalent Docker commands in kubectl. By the end of this book, you’ll have learned how to install and update an application on Kubernetes, view its logs, and inspect clusters effectively.
Table of Contents (16 chapters)
1
Section 1: Getting Started with kubectl
3
Section 2: Kubernetes Cluster and Node Management
6
Section 3: Application Management
10
Section 4: Extending kubectl

Creating a service

Kubernetes services provide a single stable name and address for a set of pods. They act as basic in-cluster load balancers.

Most pods are designed to be long-running, but when a single process dies, the pod dies with it. If it dies, the Deployment replaces it with a new pod. Every pod gets its own dedicated IP address, which allows containers to have the same port (the exception is when NodePort is used), even if they're sharing the same host. But when a pod is started by the Deployment, the pod gets a new IP address.

This is where services really help. A service is attached to the deployment. Each service gets assigned a virtual IP address that remains constant until the service dies. As long as we know the service IP address, the service itself will keep track of the pods created by the deployment and will distribute requests to the deployment pods.

By setting the service, we get an internal Kubernetes DNS name. Also, the service acts as an in-cluster...