Shulou(Shulou.com)06/03 Report--

Overview of Kubernetes

Kubernetes is an open source container orchestration engine for Google, which supports automated deployment, large-scale scalability, and application containerization management. When deploying an application in a production environment, multiple instances of the application are usually deployed to load balance application requests.

In Kubernetes, we can create multiple containers and run an application instance in each container, and then manage, discover and access this group of application instances through the built-in load balancing policy, and these details do not need to be manually configured and processed by operation and maintenance personnel.

Characteristics of Kubernetes

Portable: supports public cloud, private cloud, hybrid cloud, multiple cloud (multi-cloud)

Extensible: modular, plug-in, mountable, combinable

Automation: automatic deployment, automatic restart, automatic replication, automatic scaling / expansion

One, two ways to create resources 1. Command-based way: simple, intuitive and fast, quick to use. Suitable for temporary tests or experiments. two。 Configuration manifest-based approach: the configuration file describes the What, the state that the application will eventually achieve. The configuration file provides a template for creating resources that can be deployed repeatedly. You can manage your deployment as if you were managing code. Suitable for formal, cross-environmental, large-scale deployment. This approach requires familiarity with the syntax of the configuration file, which is difficult. The environment introduces the host IP address service master192.168.1.21k8snode01192.168.1.22k8snode02192.168.1.23k8s2. Configuration checklist (yam,yaml)

In k8s, files in yaml format are generally used to create pod that meets our expectations. Such yaml files are generally called resource lists.

/ etc/kubernetes/manifests/ K8s place to store (yam, yaml) files

* * kubectl explain deployment (you can see how the resource should be defined by adding the explain parameter to the resource category)

Kubectl explain deployment.metadata adds the fields marked with Object through the resource category, and we can see how to define the contents of the secondary fields under the first-level field.

Kubectl explain deployment.metadata.ownerReferences looks at the contents under the field by adding different levels of field names, and the preceding [] sign represents the list of objects

1. Common yaml file writing and the role of fields

(1) apiVersion:api version information

(used to define which group and which version it currently belongs to, which is directly related to which version is ultimately available.)

[root@master manifests] # kubectl api-versions// to view all current api versions

(2) kind: category of resource object

(used to define what category the created object belongs to, whether it is an object such as pod,service or deployment, which can be defined according to its fixed syntax format.)

(3) metadata: metadata name field (required)

The following fields are provided:

CreationTimestamp: "2019-06-24T12:18:48Z"

GenerateName: myweb-5b59c8b9d-

Labels: (object label)

Pod-template-hash: 5b59c8b9d

Run: myweb

Name: myweb-5b59c8b9d-gwzz5 (name of the pods object. The name of the pod object in the same category is unique and cannot be repeated)

Namespace: default (the namespace to which the object belongs, which can be repeated within the same namespace. This namespace is also a K8s-level namespace and is not confused with the container namespace)

OwnerReferences:

ApiVersion: apps/v1

BlockOwnerDeletion: true

Controller: true

Kind: ReplicaSet

Name: myweb-5b59c8b9d

Uid: 37f38f64-967a-11e9-8b4b-000c291028e5

ResourceVersion: 943

SelfLink: / api/v1/namespaces/default/pods/myweb-5b59c8b9d-gwzz5

Uid: 37f653a6-967a-11e9-8b4b-000c291028e5

Annotations (resource annotations, which need to be defined in advance, are not available by default)

The path for each resource reference is defined by these identities: that is, / api/group/version/namespaces/ namespace / resource category / object name

(4) spec: the desired state of the user

(this field is the most important because spec is the 'disired state', used to define the target status' and the lack of access to resources leads to different fields nested in the spec, and because spec is important and the fields are different, k8s built an internal description of spec for query)

(5) status: what is the current state of the resource?

(current status, the field 'current state',' is generated and maintained by a K8s cluster, cannot be customized, and belongs to a read-only field.)

two。 Write a yaml file [root@master ~] # vim web.yamlkind: Deployment # Resource object is the controller apiVersion: extensions/v1beta1 # api version metadata: # description kind (resource type) name: web # define controller name spec: replicas: 2 # number of copies template: # template metadata: labels: # tag app: web_server spec: Containers: # specify container-name: nginx # Container name image: image used by nginx # execute [root@master ~] # kubectl apply-f web.yaml check [root@master ~] # kubectl get deployments. -o wide// view controller information

[root@master ~] # kubectl get pod-o wide// View pod node information

3. Write a service.yaml file [root@master ~] # vim web-svc.yamlkind: Service # Resource object is a copy of apiVersion: v1 # api version metadata: name: web-svcspec: selector: # tag selector app: web-server # must be consistent with web.yaml tag ports: # port-protocol: TCP port: 80 # host port targetPort: 80 # container port

Use the same tag and tag selector content to associate two resource objects with each other.

For the created service resource object, the default type is ClusterIP, which means that any node in the cluster can access it. Its function is to provide a unified interface for the real back-end service pod. If you want the public network to access the service, you should change type to NodePort.

(1) execute [root@master ~] # kubectl apply-f web-svc.yaml (2) check [root@master ~] # kubectl get svc// to view controller information

(3) visit [root@master ~] # curl 10.111.193.168

4. The public network can access the service (1) modify web-svc.yaml file kind: Service # Resource object is a copy of apiVersion: v1 # api version metadata: name: web-svcspec: type: NodePort # add change network type selector: # tag selector app: web_server # must be consistent with web.yaml tag ports: # port-protocol: TCP port: 80 # Host port targetPort: 80 # Container port nodePort: 30086 # specify cluster mapping port The range is 30000-32767 (2) refresh [root@master ~] # kubectl apply-f web-svc.yaml (3) check [root@master ~] # kubectl get svc

(4) browser testing

III. Small experiments

Continue the experiment based on the previous blog post

1. Create a Deployment resource object by using a yaml file, which requires the image to use a personal private image v1 version. The replicas is 3. Write yaml file [root@master ~] # vim www.yamlkind: DeploymentapiVersion: extensions/v1beta1metadata: name: xgpspec: replicas: 3 template: metadata: labels: app: www_server spec: containers:-name: web image: 192.168.1.21:5000/web:v1 (1) execute [root@master ~] # kubectl apply-f web-svc.yaml (2) check [root@master ~] # kubectl get deployments. -o wide// view controller information

[root@master ~] # kubectl get pod-o wide// View pod node information

(3) visit

two。 Create a Service resource object by using the yaml file. To associate with the above Deployment resource object, the type type is: NodePort, and the port is: 30123. Write the service file [root@master ~] # vim www-svc.yamlkind: ServiceapiVersion: v1metadata: name: www-svcspec: type: NodePort selector: app: www_server ports:-protocol: TCP port: 80 targetPort: 80 nodePort: 30123 execute [root@master ~] # kubectl apply-f www-svc.yaml to check [root@master ~] # kubectl get svc

Make a visit.

four。 Summary 1. The role of Pod

Pod is the smallest management unit in K8s and usually contains one or more containers in a pod. In most cases, there is only one Container container in a Pod.

There is a special Pause container and one or more business containers in each Pod. The Pause comes from the pause-amd64 image, and the Pause container plays a very important role in the Pod:

As the root container of the Pod container, the Pause container is locally independent of the business container, and its state represents the state of the entire pod. Multiple business containers in Pod share the IP of Pause containers, each Pod is assigned an independent IP address, and each container in Pod shares a network namespace, including IP addresses and network ports. Containers within Pod can use localhost to communicate with each other. K8s supports communication between any two Pod in the underlying network cluster. All containers in the Pod have access to the shared volumes, allowing these containers to share data. Volumes is also used for data persistence in Pod in case one of the containers needs to be restarted and the data is lost. 2. The role of Service

Service is an abstraction of real back-end services. A Service can represent multiple identical back-end services.

Service provides a fixed access endpoint for the POD cluster controlled by the POD controller, and Service's work also depends on an attachment in K8s, CoreDNS, which provides a domain name resolution of the Service address.

Service of type NodePort

ClusterIP: specifies which IP of the service network Service is located in. The default is dynamic allocation.

NodePort is a nodePort exposed to node's network namespace on the ClusterIP type, so users can access the cluster from outside the cluster, so the user's request flow is: Client-> NodeIP:NodePort-> ClusterIP:ServicePort-> PodIP:ContainerPort.

It can be understood that NodePort enhances the function of ClusterIP, so that clients can access any nodeip outside each cluster to access clusterIP, and then load balance from clusterIP to POD.

3. Flow trend

After we have created a service, the user should first access the ip of the nginx reverse proxy, then access the NodePort of the backend K8s server (master node) through nginx to expose IP and the mapped port, and access the information of the backend K8s node through the "ip+ mapping port" of the "master node".

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.