In this chapter, we will start by creating different kinds of resources on the Kubernetes system. In order to realize your application in a microservices structure, reading the recipes in this chapter will be a good start towards understanding the concepts of the Kubernetes resources and consolidating them. After you deploy applications in Kubernetes, you can work on its scalable and efficient container management, and also fulfill the DevOps delivering procedure of microservices.

Working with Kubernetes is quite easy, using either a Command Line Interface (CLI) or API (RESTful). This section will describe Kubernetes control by CLI. The CLI we use in this chapter is version 1.10.2.

After you install Kubernetes master, you can run a kubectl command as follows. It shows the kubectl and Kubernetes master versions (both the API Server and CLI are v1.10.2):

$ kubectl version --short
Client Version: v1.10.2
Server Version: v1.10.2

kubectl connects the Kubernetes API server using the RESTful API. By default, it attempts to access the localhost if .kube/config is not configured, otherwise you need to specify the API server address using the --server parameter. Therefore, it is recommended to use kubectl on the API server machine for practice.

The Pod is a group of one or more containers and the smallest deployable unit in Kubernetes. Pods are always co-located and co-scheduled, and run in a shared context. Each Pod is isolated by the following Linux namespaces:

• The process ID (PID) namespace
• The network namespace
• The interprocess communication (IPC) namespace
• The unix time sharing (UTS) namespace

In a pre-container world, they would have been executed on the same physical or virtual machine.

It is useful to construct your own application stack Pod (for example, web server and database) that are mixed by different Docker images.

You must have a Kubernetes cluster and make sure that the Kubernetes node has accessibility...

A ReplicaSet is a term for API objects in Kubernetes that refer to Pod replicas. The idea is to be able to control a set of Pods' behaviors. The ReplicaSet ensures that the Pods, in the amount of a user-specified number, are running all the time. If some Pods in the ReplicaSet crash and terminate, the system will recreate Pods with the original configurations on healthy nodes automatically, and keep a certain number of processes continuously running. While changing the size of set, users can scale the application out or down easily. According to this feature, no matter whether you need replicas of Pods or not, you can always rely on ReplicaSet for auto-recovery and scalability. In this recipe, you're going to learn how to manage your Pods with ReplicaSet:

The ReplicaSet usually handles a tier of...

The Deployment API was introduced in Kubernetes version 1.2. It is replacing the replication controller. The functionalities of rolling-update and rollback by replication controller, it was achieved with client side (kubectl command and REST API), that kubectl need to keep connect while updating a replication controller. On the other hand, Deployments takes care of the process of rolling-update and rollback at the server side. Once that request is accepted, the client can disconnect immediately.

Therefore, the Deployments API is designed as a higher-level API to manage ReplicaSet objects. This section will explore how to use the Deployments API to manage ReplicaSets.

In order to create Deployment...

The network service is an application that receives requests and provides a solution. Clients access the service by a network connection. They don't have to know the architecture of the service or how it runs. The only thing that clients have to verify is whether the endpoint of the service can be accessed, and then follow its usage policy to get the response of the server. The Kubernetes Service has similar ideas. It is not necessary to understand every Pod before reaching their functionalities. For components outside the Kubernetes system, they just access the Kubernetes Service with an exposed network port to communicate with running Pods. It is not necessary to be aware of the containers' IPs and ports. Behind Kubernetes Services, we can fulfill a zero-downtime update for our container programs without struggling:

Files in a container are ephemeral. When the container is terminated, the files are gone. Docker has introduced data volumes to help us persist data (https://docs.docker.com/engine/admin/volumes/volumes). However, when it comes to multiple hosts, as a container cluster, it is hard to manage volumes across all the containers and hosts for file sharing or provisioning volume dynamically. Kubernetes introduces volume, which lives with a Pod across a container life cycle. It supports various types of volumes, including popular network disk solutions and storage services in different public clouds. Here are a few:

Kubernetes Secrets manage information in key-value formats with the value encoded. It can be a password, access key, or token. With Secrets, users don't have to expose sensitive data in the configuration file. Secrets can reduce the risk of credential leaks and make our resource configurations more organized.

Currently, there are three types of Secrets:

• Generic/Opaque: https://en.wikipedia.org/wiki/Opaque_data_type
• Docker registry
• TLS

Generic/Opaque is the default type that we're using in our application. Docker registry is used to store the credential of a private Docker registry. TLS Secret is used to store the CA certificate bundle for cluster administration.

For assigning a name to the Pod, follow the following steps:

1. The following example is the...

In a Kubernetes cluster, the name of a resource is a unique identifier within a Namespace. Using a Kubernetes Namespace could separate user spaces for different environments in the same cluster. It gives you the flexibility of creating an isolated environment and partitioning resources to different projects and teams. You may consider Namespace as a virtual cluster. Pods, Services, and Deployments are contained in a certain Namespace. Some low-level resources, such as nodes and persistentVolumes, do not belong to any Namespace.

Before we dig into the resource Namespace, let's understand kubeconfig and some keywords first:

kubeconfig is used to call the file which configures the access permission of Kubernetes clusters. As the original configuration of the system, Kubernetes takes $HOME/.kube/config as a kubeconfig...