How is Docker related to Kubernetes? This is probably the question we all had when we first came into contact with Kubernetes. So what is Kubernetes?

Kubernetes is a container cluster scheduling management system, used to achieve automatic container cluster deployment, automatic capacity expansion and other functions. Docker provides container technology for running applications, while Kubernetes itself does not provide containers for running applications, but manages containers.

After understanding the relationship between Docker and Kubernetes, we can understand why we need to learn Docker first and then Kubernetes, which is the same as learning Spring framework first to better learn Spring Boot and Spring Cloud. If you do not know about Docker, you can first read the previous article “Docker for operation and maintenance knowledge that Development also needs to know”.

As developers, why do we need to understand container technology? Isn’t that what operations is supposed to learn? As a developer, you need to understand the container technology to be able to choose the appropriate technology and what issues you should pay attention to when developing applications deployed on top of Kubernetes container services. If operations don’t know the code, and development doesn’t know Kubernetes, who can solve the problems of migrating services to Kubernetes?

Kubernetes

I learned the route of Kubernetes and shared it with you:

  • Official learning document: docs.kubernetes.org.cn/
  • Book to read:Kubernetes in ActionChinese version of”
  • Geek Time video tutorial:Spring CloudwithKubernetesCloud Native Micro-service Combat

To learn Kubernetes, first understand the architecture of Kubernetes, understand some “concepts”, and then understand the configuration file. Configuration files for beginners is the most difficult to understand, so I recommend you to read “Kubernetes in Action Chinese” this book, follow the example step by step to master the role of each kind of configuration files, the role of each configuration item is what.

Kubernetes manages all available physical machines. Take Ali Cloud container service Kubernetes as an example. Kubernetes is responsible for managing a bunch of ECS instances, which requires us to buy enough ECS instances, at least two, when we create Kubernetes cluster. You can also add newly purchased ECS instances to the Kubernetes cluster, which is managed by Kubernetes.

Developers and operations do not need to know a application deployment in which ECS instance, only need to specify the needed to run the application resources such as CPU, memory, Kubernetes will be calculated according to the requirement to satisfy conditions of nodes (ECS), and the node (ECS) from the image on the warehouse pull mirror create containers and run the application, And monitor the entire lifecycle of the container. We can think of all nodes (ECS) managed by Kubernetes as a large physical machine. The CPU and memory of this large physical machine are the sum of all nodes (ECS).

Kubernetes in Action

As shown above, the developer simply constructs the application as an image, pushes the image to a remote image repository, and writes a configuration file that describes the resources needed to run the application image, where the image is pulled, and so on. Use Kubectl to call the API provided by Kubernetes to deploy the application to Kubernetes.

Kubernetes consists of two types of nodes.

Kubernetes in Action

One is the Master node, which controls and manages the entire cluster. To achieve high availability, the Master node also needs to deploy clusters. Components are deployed on the master node, which can run on a single master node or be deployed on multiple master nodes via replicas for high availability. For example, etCD, a data consistency storage service based on Raft protocol, Kubernetes API service for our use, Scheculer component for scheduling application deployment, and Controller Manager component for performing cluster functions. We can look at these components so briefly that we don’t have to go too far.

The other is the work node, which runs the application that the user actually deploys.

Assuming that we have purchased the hosted Kubernetes service in Ali Cloud, the master node is hosted by Ali Cloud, and the working node is the ECS instance we have purchased. The number of ECS instances in a cluster is the number of working nodes.

A work node is a machine that runs containers, and in addition to the containers that run our deployed applications, each work node runs components that run, monitor, and manage application services. Such as Docker, Kubelet, kube-proxy. We’re already familiar with Docker; Kubelet is responsible for communicating with the Kubernetes API service of the master node and managing the container of the work node where it resides; Kube-proxy is responsible for load balancing network traffic between components.

The diagram above shows an application deployment flowchart based on what we’ve learned about Kubernetes so far.

  • 1. Developers build application images on the local machine;
  • 2. The developer will mirror the local applicationpsuhTo the mirror warehouse;
  • 3. Developers write a description file for running the application (yamlConfiguration file);
  • 4. Use by developerskubectlcallKubernetes APISubmit the application description file toKubernetes;
  • 5,SchedulerThe component deploys the application based on the description file scheduling work node;
  • 6, on the work node byContainer runtimeResponsible for pulling images from the mirror repository, creating containers, and running containers;

In actual project deployment, the network and container parts are probably the most difficult to understand. For example, when we deploy an application that requires SSD resources without using Kubernetes, we first buy SSDS and mount them on the server. When using Kubernetes, we tell Kubernetes to deploy the application only on nodes that have SSDS. Network and container volume content is still a lot of very complex, this paper will not introduce more, and will be introduced in the subsequent articles, of course, it is only a simple understanding and how to use, because the author does not understand much.

Some concepts to know:

Namespaces: Identifies resources such as test environment resources and production environment resources. You can also use labels. If you do not specify namespaces, the default namespace is default. If you do not specify a non-defalut namespace, you need to specify namespaces in kubectl to create secret and service accounts.

Node: Nodes are actual machines or virtual machines, such as Ali Cloud ECS.

Pod: A Pod is the minimum basic unit Kubernetes creates or deploys. A Pod encapsulates one or more application containers, storage resources, a separate network IP, and policy options that govern how the container operates.

Kubernetes in Action

As shown in the figure above, when a Pod contains multiple containers, the containers always run on the same working node and do not span multiple working nodes. For example, if we deploy a Java program, we can run multiple containers of the Java program in a Pod. A Pod can encapsulate tightly coupled applications that need to be made up of multiple containers that can share resources, such as front and back ends deployed together (this example is not appropriate). For developing Java microservices applications, a Pod usually only runs one container, so you don’t have to worry too much about these concepts at first.

Service: A Service abstraction is a logical group of pods that can be accessed by a Service, usually via a Label or Selector. Such as:

apiVersion: v1
kind: Service
metadata:
  name: demo-srv-service
  namespace: sit
spec:
  selector:
    app: demo-srv
    env: sit
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
Copy the code

Matches a group of Pod whose app is demo-srv and env is sit by selector. This group of Pod corresponds to the service demo-srv-service. To simplify things a bit, suppose we deploy a Java program, and one Pod starts only one container for that Java program. Then starting multiple Pods of that Java program corresponds to multiple pods of the same Service.

ReplicationController: ReplicationController (RC for short) ensures that the number of user – defined Pod copies remains unchanged. Within a user-defined range, such as specifying 3 clusters for a Java program to deploy, RC terminates additional pods if they exceed 3(for example, manually start), and creates new pods if they are less than 3(for example, due to memory outages), always within the defined range.

ReplicaSet: ReplicaSet is an upgraded version of RC. The only difference between RS and RC, which I won’t cover here, is support for selectors.

Deployments: Deployment provides declarative updates for Pod and ReplicaSet. All you need to do is describe what your desired target state is in the Deployment and the Deployment Controller will help you change the actual Pod and ReplicaSet states to your target state.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-srv-deployment
  namespace: sit
spec:
  # Number of copies, how many 'pods' to run
  replicas: 3
  # selector, using tag matching
  selector:
    matchLabels:
      app: demo-srv
  template:
    metadata:
      # label
      labels:
        app: demo-srv
        env: sit
    spec:
      # container, specifying multiple containers will run multiple containers within a Pod
      containers:
        - name: demo-srv
          image: registry.cn-shenzhen.aliyuncs.com/wujiuye/demo-srv
Copy the code

DaemonSet: Ensure that only one Pod of the application runs on each node (physical machine or virtual machine). Such as ali cloud implementation of diary collection, is running on each node for the collection of diary application container, corresponding to a Pod.

Network communication between PODS:

All pods in the Kubernetes cluster are in the same shared network address space, which means that each Pod can access each other through the IP addresses of other pods. This also means that there is no NAT gateway between them. When two PODS send network packets to each other, they treat each other’s actual IP address as the source IP in the packet.

Whether two pods are arranged on a single or different working node, and regardless of the network topology between the actual nodes, containers within these PODS can communicate just like computers on a LAN.

Network communication between services:

Kubernetes Service provides a single unchanging access point for a set of pods with the same functionality. When a service exists, its IP address and port do not change. The client establishes connections using IP addresses and port numbers, and these connections are routed to any Pod that provides the service for load balancing. In this way, the client does not need to know the address of each individual service Pod, so that these pods can be created or removed from the cluster at any time.

Suppose you have a project that has two microservices, demo-SRV and Demo-Cap. Now deploy these two services on the Alicloud container service Kubernetes. In the service list page of the console, you can see that both of these two services have a cluster IP. No matter how many pods are deployed in these two services, no matter how many pods are changed, other services can access the Pod behind this cluster IP. Of course, the access behind the Pod is also load balancing.

Because of this, the Service discovery we developed for microservice implementations was service-based, making it unnecessary to implement load balancing in the application.

Type:

  • ClusterIP: Through the clusterIPExpose service, select this value, service can only be inKubernetesAccess is available within the cluster.
  • NodePort: Through eachNodeOn theIPAnd static ports (nodeports) expose the service.NodePortThe service will route toClusterIPService, thisClusterIPThe service is automatically created. By request<NodeIP>:<NodePort>, can be accessed from outside the clusterNodePortService.
  • LoadBalancer: If the load weighing device provided by Ali Cloud is used, the service can be exposed to the outside. External load balancers can be routed toNodePortServices andClusterIPService.

This introduction to this, Kubernetes to learn a lot of knowledge points, but as a development, we may not go to too much attention to some details, this introduction is the knowledge points I think as a development should master the knowledge. It is recommended to know more about the deployment of network and container volume. Network is related to the call between services, while container volume is related to the printing and file storage of diary. If ali cloud container service is used, we can not output diary to files and use the diary service provided by Ali to collect diary. However, if you need a persistent storage service, you must understand the container Volume.

Don’t understand the concept of can refer to the official documentation: http://docs.kubernetes.org.cn want to learn more or recommend reading the Kubernetes Action “in Chinese version