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

This article mainly introduces "what is the object model". In the daily operation, I believe that many people have doubts about what the object model is. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "what is an object model"! Next, please follow the editor to study!

An overview of the object model

K8s can be seen as object-oriented, and each type of service can be seen as an object of K8s. These objects are created by the api of the user-defined yaml,k8s. All objects contain two kinds of basic information: spec (specification) + status.

For example, the api for creating pod in K8s is: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/#pod-v1-core

Kubectl also converts yaml to json and sends it to the master node.

The commonly used objects in K8s are pod, deployment, service, statefulSet and so on, and each object contains at least 3 metadata:namespace, name and uid.

Second, the common object kind in k8s

Pod

Basic scheduling unit, a set of containers for specific relationships, and the smallest set of deployments.

Non-persistent entities, such as scheduling failure and self-healing, will be terminated and rebuilt. It is not recommended to create Pod manually, but to create pod through controller, such as deployment.

Service

Ip will change after pod restart, and discovery+loadbalance is required for multiple pod of the same service. This is consistent with the concept in "microservices". Logical grouping can be easily implemented through label selector.

Ip does not change during the declaration cycle of service. Can be exposed to the outside through nodeport.

Some service do not need ip, and some service do not need load balancing.

Controllers

Number of Replicaset (rs) replicas for loadbalance and redundancy. (the old version is ReplicationController- rc, which is a feature upgrade, and it is officially recommended to use rs instead of rc.) For non-special cases such as upgrading pod at this stage, it is not recommended to use it alone.

Deployment

Using and managing rs is a higher-level concept, which is now the more common way to deploy app. Deployment provides declarative updates (rather than imperative) for pod and rs. Support for rolling updates (rollingUpdate) and rollback operations.

StatefulSet (k8s 1.9 GA)

Our own applications are generally stateless, such as redis, zk, kafka, mysql and other middleware usually need to use statefulSet. It is usually suitable for scenarios with stable persistent storage, stable network identification, orderly deployment, orderly expansion, orderly contraction, and orderly rolling upgrade.

Pod storage is generally volumes plug-in to persistent media. And scaling or deleting does not delete the associated storage. Headless service is required to be responsible for the network identity of pod.

"Note: the service corresponding to statefulSet is headless servie, which differs from a normal service in that it has cluster ip, only service has dns, and loads are carried out through iptables. Headless service No cluster ip,endpoints is the dns address of all pod. This means that statefulset generates dns information for pod when it creates the pod. For example, a 3-node mysql will generate mysql-0. Mysql-2 has three pod (the production rule of pod name is pod+ increment serial number), and the domain: $(podname). (headless server name) is generated, and the complete FQDN is: $(podname). (headless server name) .namespace.svc.cluster.local "

Look at a complete example of statefulSet + headless service.

ApiVersion: v1kind: Servicemetadata: name: nginx labels: app: nginxspec:-port: 80 name: web clusterIP: None selector: app: nginx---apiVersion: apps/v1beta1kind: StatefulSetmetadata: name: webspec: serviceName: "nginx" replicas: 1 template: metadata: labels: app: nginxspec: containers:-name: nginx image: nginx:1.11 ports:- ContainerPort: 80 name: web volumeMounts:-name: www mountPath: / usr/share/nginx/html nodeSelector: node: kube-node3 volumes:-name: www hostPath: path: / mydir

DeamonSet

Each node has a copy of pod running. Commonly used in background resident programs such as ceph, log collection, heartbeat check, Prometheus exporter and so on.

ConfigMap

Provide pod with non-sensitive configuration information, support for key-value pairs, individual attributes, and configuration files.

Usage: environment variables, container command line parameters, data volume mount.

Example of definition:

ApiVersion:V1kind:ConfigMapmetadata: name:hello-config namespace:public-configdata: title:hello everybody sex:girl

Reference example:

ApiVersion:V1kind:deploymentmetadata: name:hello-demspec: containers:-name:goodboy image:hub/images command: ["/ bin/bash", "- c" "echo ${envTitle} ${envSex}"] env:-name:envTitle valueFrom: configMapKeyRef: name:hello-config key:title-name:envSex valueFrom: configMapKeyRef: name:hello-config key:sex

Secret

Corresponding to ConfigMap, used for sensitive information configuration, such as token, password, secret key, etc.

Endpoints

The relationship between service and pod creates an endpoint object with the same name as service by default. Kube-proxy will listen for changes in service and endpoint, thus updating the rules of iptables.

PodDisruptionBudget (pdb, active eviction protection)

There is no pdb. When maintaining a node, if multiple pod of a service are on the node, the downtime of the node may cause service interruption or service degradation. For example, a service has five pod, and a minimum of three pod can guarantee the quality of service, otherwise it will cause slow response and other impacts. If the four pod of the service is on the node01, if the node01 is downtime and maintenance, only one pod can be served normally. During the four pod migration process of the node01, the normal response of the service will be affected.

Pdb can ensure that the application runs no less than a certain number of pod during node maintenance, thus maintaining the quality of service.

Wait, others, like ingress.

Third, there is a common metadata in k8s

Name & & UID (uid is unique in the entire declaration cycle of k8s and does not produce the same uid, but is equivalent to the auto increment key of mysql)

Let's take a look at the path of an api access object: / api/ {version} / namespaces/ {namespace} / {object-kind} / {name}. K8s uses layers of qualification to find the name that is uniquely identified.

Namespace

The abstract collection of a group of resources and objects is logically divided into k8s to realize hierarchical management, and to achieve the isolation of resources and permissions at a certain level.

Built-in three namespace:default,kube-system (store api-server, dns plug-ins, etc.) and kube-public (for all users to include unauthenticated users to share resources within the cluster)

Node and persistentVolume (PV for short, bound by PVC and pod) do not belong to any namespace.

Label

For identifying data, there is a strict naming convention. K8s can manage objects through tag combination to achieve loose coupling. Matching is done through selectors in spec.

Annotation (understood as java comment)

Non-identifiable metadata is attached to the object. There is usually auxiliary information such as timestamp, version number, user information and so on.

4. Common parameters in k8s spec

Selectors (tag and tag selector)

Select objects corresponding to the key-value corresponding to label

5. The ip model of K8S

Ip of K8s:

Node Ip: the ip of the node node, which is physical ip.

The ip of pod Ip:pod, that is, the ip of the docker container, is the virtual ip.

Ip of cluster Ip:service, which is a virtual ip. Provide a virtual IP within the cluster for Pod access.

6. Volume of K8s

The volume and docker of K8s are different. V is independent of the container and is the same as the pod declaration period, that is, the pod deletion space is also deleted. There are multiple types

Emptydir

Empty directory, which is shared by containers in pod

As shown below, the busybox file is written and can be read in the nginx container.

[root@master ~] # cat test.yaml apiVersion: v1kind: Servicemetadata: name: defaultspec: type: NodePort selector: app: mynginx ports:-name: nginx port: 80 targetPort: 80 nodePort: 30080---apiVersion: apps/v1kind: Deploymentmetadata: name: deploy namespace: defaultspec: replicas: 1 selector: matchLabels: app: mynginx template: metadata: labels: app: mynginx spec: containers: -name: mynginx image: lizhaoqwe/nginx:v1 volumeMounts:-mountPath: / usr/share/nginx/html/ name: share ports:-name: nginx containerPort: 80-name: busybox image: busybox command:-"/ bin/sh"-"- c"-"sleep 4444" volumeMounts :-mountPath: / data/ name: share volumes:-name: share emptyDir: {} so far The study on "what is the object model" is over, hoping to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.