Kubernetes has many technical concepts and API objects, each can be extended to talk about a lot, according to the previous learning ideas, or first understand about.

Pod

The official explanation for Pod is this:

A Pod is the smallest deployable cell that can be created and managed in Kubernetes.

Pod is designed to allow multiple containers to share network addresses and file systems in a Pod. Services can be combined in a simple and efficient way through interprocess communication and file sharing.

A simple example: for example, we design a product related services, including the commodities management and synchronization (goods) can be drawn from other sources in two parts function, in the design, we are likely to put the two parts into two independent small applications and are done by two groups, respectively (hypothetical). In this case, different teams can develop and build their own container images, which can be combined into a microservice to provide services externally during deployment and build a Pod.

The relationship between PODS is shown as follows:

Containers between pods can access each other using localhost and mount all data volumes in pods. However, containers between different PODS cannot be accessed using localhost, and data volumes of other pods cannot be mounted.

Volume

Kubernetes cluster storage volume is similar to Docker storage volume, but Docker storage volume scope is a container, while Kubernetes storage volume life cycle and scope is a Pod. The storage volumes declared in each Pod are shared by all containers in the Pod. Kubernetes supports a wide variety of storage volume types. In particular, Kubernetes supports storage on multiple public cloud platforms, including AWS, Google, and Azure. Supports a variety of distributed storage including GlusterFS and Ceph; Easy to use host-local directories emptyDir, hostPath, and NFS are also supported.

Deployment, ReplicaSet, Replication Controller

As mentioned above, the Master node contains the Controller Manager component, among which some specific controllers include Deployment, ReplicaSet and Replication Controller, which are equivalent to a state machine. Used to control the specific state and behavior of the POD.

  • ReplicaSet, the Replication of the Controller

    Let’s start with Replication Controller, RC. RC guarantees that a specified number of Pod copies can be run at the same time, ensuring that pods are always available. If the actual number of pods is larger than the specified number, the excess is terminated, and if the actual number is smaller than the specified number, the missing is started. When a Pod fails, is deleted, or is terminated, RC automatically creates a new Pod to ensure the number of copies. So even one Pod should be managed using RC.

    ReplicaSet (RS for short), with the development of Kubernetes, has officially recommended that we use RS and Deployment instead of RC. RS objects are generally not used alone, but as an ideal state parameter for Deployment. The only difference between RS and RC is that RC only supports equal-based selectors (env=dev or environment! = QA), but RS also supports collection-based selector (version in (v1.0, V2.0)), which is handy for complex operations and maintenance management.

  • Deployment

    Deployment is also a core concept of Kubernetes system. The main responsibility of Deployment, like RC, is to ensure the number and health of Pod. Most of the functions of the two are completely the same, so we can regard it as an upgraded RC controller. In addition to the capabilities contained in RC, Deployment has the following features:

    • View events and status: You can view events and statusDeploymentThe detailed upgrade progress and status of
    • Rollback: When upgradingPodIf a problem occurs, you can use the rollback operation to roll back to any previous version
    • Version record: Each pairDeploymentAll operations can be saved, which is the basis for ensuring that you can roll back to any version
    • Pause and Start: Can be paused and started at any time for each upgrade

  • Deployment and ReplicaSet relationship

    Seeing this, one might ask why a Deployment object is required when you have ReplicaSet and everything is similar. The general structure of the two is shown as follows:

    We take the scenario of rolling upgrade of a service to illustrate that rolling upgrade of a service is actually a compound operation of creating a new RS and gradually increasing the number of copies in the new RS to the ideal state and reducing the number of copies in the old RS to 0. Such a composite operation is not well described in an RS, so a more general Deployment is used to describe it.

    My personal understanding, to take an inappropriate example, is that the anaemia model in the similar domain model is similar to the hyperemia model, RS objects are more like anaemia model, only retaining attributes. The Deployment object, which contains properties and behaviors, is more applicable. It is also strongly recommended that we use Deployment and RS to manage pods.

Service

The definition of Service in the official documentation:

An abstract way to expose an application running on a set of Pods as a web service.

With Kubernetes, you can use unfamiliar service discovery mechanisms without modifying your application. Kubernetes provides its own IP address for Pods and the same DNS name for a group of Pods, and can load balance between them.

As you can see, Service objects provide two capabilities: enabling pods to be discovered by services and load balancing. The reason for this is that the Service object itself does neither of these things. A Service is an abstract object that defines a logical set of PODS and a policy for accessing them. The concept is very similar to microservices.

  • Why do WE need a Service object?

    RC, RS, and Deployment only guarantee the number of microservice pods supporting services, but do not solve the problem of how to access these services. A Pod has a life cycle. They can be created and destroyed without being restarted. If you use Deployment to run your application, it can create and destroy pods dynamically. Each Pod has its own IP address, but in Deployment, the Pod set running at the same time may be different from the Pod set running the application later and therefore cannot be served with the identified IP and port number.

    A Service object defines a logical set of pods and a policy for accessing them. In a Kubernetes cluster, the Service object is the one that clients need to access. Each Service corresponds to a valid virtual IP address in the cluster. The cluster accesses a Service through this virtual IP address.

Job/Cronjob

In our daily work, we often meet some demands for batch data processing and analysis. Of course, there will also be scheduling work according to time. In our Kubernetes cluster, two resource objects, Job and CronJob, are provided for us to deal with such demands. Job is responsible for processing tasks, that is, tasks that are executed only once, and it ensures that one or more pods of the batch task successfully terminate. A CronJob adds time scheduling to a Job.

Namespace

Namespace provides virtual isolation for the Kubernetes cluster. The Kubernetes cluster initially has two namespaces: default Namespace and kube-system Namespace. Administrators can create new namespaces to meet requirements.

While the concepts mentioned above are intended to serve pods, namespace is intended to serve the entire Kubernetes cluster. Is to divide a Kubernetes cluster into several virtual clusters whose resources cannot be shared.

other

There are some other core resource objects, but they don’t seem to have much impact on the next cluster deployment practice, so I’ll add them later.