Book Image

The Complete Kubernetes Guide

By : Jonathan Baier, Gigi Sayfan, Jesse White
Book Image

The Complete Kubernetes Guide

By: Jonathan Baier, Gigi Sayfan, Jesse White

Overview of this book

If you are running a number of containers and want to be able to automate the way they’re managed, it can be helpful to have Kubernetes at your disposal. This Learning Path guides you through core Kubernetes constructs, such as pods, services, replica sets, replication controllers, and labels. You'll get started by learning how to integrate your build pipeline and deployments in a Kubernetes cluster. As you cover more chapters in the Learning Path, you'll get up to speed with orchestrating updates behind the scenes, avoiding downtime on your cluster, and dealing with underlying cloud provider instability in your cluster. With the help of real-world use cases, you'll also explore options for network configuration, and understand how to set up, operate, and troubleshoot various Kubernetes networking plugins. In addition to this, you'll gain insights into custom resource development and utilization in automation and maintenance workflows. By the end of this Learning Path, you'll have the expertise you need to progress from an intermediate to an advanced level of understanding Kubernetes. This Learning Path includes content from the following Packt products: • Getting Started with Kubernetes - Third Edition by Jonathan Baier and Jesse White • Mastering Kubernetes - Second Edition by Gigi Sayfan
Table of Contents (26 chapters)
Title Page
Copyright and Credits
About Packt
Contributors
Preface
Index

Understanding the Kubernetes networking model


The Kubernetes networking model is based on a flat address space. All pods in a cluster can directly see each other. Each pod has its own IP address. There is no need to configure any NAT. In addition, containers in the same pod share their pod's IP address and can communicate with each other through localhost. This model is pretty opinionated, but, once set up, it simplifies life considerably both for developers and administrators. It makes it particularly easy to migrate traditional network applications to Kubernetes. A pod represents a traditional node and each container represents a traditional process.

Intra-pod communication (container to container)

A running pod is always scheduled on one (physical or virtual) node. That means that all the containers run on the same node and can talk to each other in various ways, such as the local filesystem, any IPC mechanism, or using localhost and well-known ports. There is no danger of port collision...