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

This article will explain in detail the meaning of the kubernetes field in K8s. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

InitialDelaySeconds

How many seconds to wait after the container starts before kubelet starts to execute the probe. The default is 0 seconds, and the minimum value is 0.

PeriodSeconds

The interval (in seconds) at which the probe is performed. The default is 10 seconds. The minimum value is 1

TimeoutSeconds

Probe timeout. If it exceeds this time, the probe is considered to have failed. The default value is 1 second. The minimum value is 1.

SuccessThreshold

After failure, the detector is regarded as the minimum number of consecutive successes. The default value is 1. The value of the survival probe must be 1. The minimum value is 1

FailureThreshold

The number of retries if the probe fails. When detecting for survival, the container is restarted when the threshold is reached. Pod is labeled NotReady when it is ready to probe. The default value is 3. The minimum value is 1.

SubPath

When a Volume is used for multiple containers, a directory is created according to the key given by subPath. In this example, when the Volume site-data is used in separate mysql and php containers, the contents of the html are mapped to the site-data volume's html subdirectory, while the database is stored in the site-data volume's mysql directory.

ApiVersion: v1

Kind: Pod

Metadata:

Name: my-lamp-site

Spec:

Containers:

-name: mysql

Image: mysql

VolumeMounts:

-mountPath: / var/lib/mysql

Name: site-data

SubPath: mysql

-name: php

Image: php

VolumeMounts:

-mountPath: / var/www/html

Name: site-data

SubPath: html

Volumes:

-name: site-data

PersistentVolumeClaim:

ClaimName: my-lamp-site-dataresourceVersion

The string used to identify the resource build number, when used in the Watch operation, can avoid the information inconsistency between the GET operation and the next Watch operation, and the client can use it to determine whether the resource has changed. This value should be considered opaque by the client and returned to the server without any modification. Clients should not assume that version information has meaning across namespaces, different resource categories, and different servers.

GenerationterminationGracePeriodSeconds

Steps for rolling upgrade of K8S:

K8S first starts a new PODK8S and waits for the new POD to enter the Ready state K8S to create the Endpoint, add the new POD to the load balancer K8S to remove the Endpoint related to the old pod, and set the old POD status to Terminating. At this time, no new request will arrive at the old pod and K8S will send a SIGTERM signal to the old pod and wait for terminationGracePeriodSeconds for such a long time. (default is 30 seconds) after the terminationGracePeriodSeconds wait time is exceeded, K8S will force the end of the old PODtier.

Labels:

Component: kube-controller-manager

Tier: control-plane

"tier": "frontend", "tier": "backend", "tier": "cache"

Tier means a row similar to the ladder seats in a cinema, with a hierarchical meaning in it.

It can be simple for layering within the architecture. Generally set to front-end, back-end, cache, control plane these values

BlockOwnerDeletion

The root object is rs and the slave object is pod.

If blockOwnerDeletion: true is set under the ownerReferences field of pod, when deleting the rs, the rs will be deleted after the pod is deleted.

In previous blog posts, I described how to configure kubelet to delete useless image, normal or abnormal termination of container that will not start again according to policy, so as to save resources. The objects recycled by kubelet are at the container level. What about objects at the kubernetes level, such as pod, ReplicaSet, Replication Controller, Deployment, StatefulSet, DaemonSet, etc., for garbage collection?

In fact, the above kubernetes objects are not supposed to generate garbage, and the objects always exist unless the user or some kind of controller deletes the objects. It's not very accurate to call it "Garbage Collection" here, but it's actually about how to control dependencies between objects when performing a delete operation. For example, if the Deployment object creates the ReplicaSet object and the ReplicaSet object creates the pod object, do you need to delete the ReplicaSet and pod that depend on it when you delete the Deployment?

From object to root object (Owners and dependents)

Some kubernetes objects are owner of other objects. For example, the ReplicaSet object is the owner of the pod object it manages, which is called the "root object" in this article. On the other hand, the managed pod to ReplicaSet has dependent,pod objects that point to their dependent objects through the metadata.ownerReferences field, which is called "slave objects" in this paper. In kubernetes1.8, ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job and CronJob automatically adds the value of the metadata.ownerReferences field to the object it creates and adopts, but it can also be set manually.

How do I control garbage collection to delete from objects?

When you delete an object, you can control how it is deleted from the object. Automatic deletion from the object is called cascading deletion (cascading deletion). There are two ways: background and foreground. You can also delete only the root object without deleting the slave object.

1. Foreground cascade deletion

When the foreground is cascaded to delete, the root object first enters the "deletion in progress" state. In the "deletion in progress" state, the following facts exist:

If you access the root object through REST API, it is still visible.

The deletionTimestamp of the root object is set.

The root object metadata metadata.finalizers contains "foregroundDeletion".

Once the state of the root object is set to "deletion in progress", the garbage collector starts to delete from the object. If there is an object from the object

The "ownerReference.blockOwnerDeletion=true" property, then the garbage collector must wait until this class has been deleted from the object before deleting the root object. Otherwise, the garbage collector starts deleting the root object as soon as it is deleted from the object.

"ownerReference.blockOwnerDeletion=true" delays the deletion of the root object. An admission controller has been added to the kubernetes1.7 version, which controls the operation of setting ownerReference.blockOwnerDeletion to true according to the access rights of the root object to prevent unauthorized users from setting the

The value of ownerReference.blockOwnerDeletion is set to true, thus delaying the deletion of the root object.

If the ownerReferences of the slave object is set by some controller, it is best for the user not to modify its value manually.

two。 Backstage cascade deletion

When the backend is cascaded to delete, kubernetes immediately deletes the root object and returns. The garbage collector deletes it from the object in the background.

3. Do not delete slave object

Deleting only the root object does not delete the slave object, which is called "Orphan", and the remaining slave object becomes an "orphan".

Set deletion policy during specific operation

When executing a specific operation request, select one of the above three deletion strategies by setting the "propagationPolicy" field in the delete request to "Orphan", "Foreground", or or "Background".

Before kubernetes1.9, the default policy for deleting most controllers was "Orphan" (note that the default value in this paragraph refers to the default behavior of REST API, not the kubectl command), including ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and Deployment, that is, the slave object is not deleted when the root object is deleted. And when apiVersion is extensions/v1beta1, apps/v1beta1, and apps/v1beta2, unless otherwise specified, the default deletion policy is still "Orphan". In the kubernetes1.9 version, all types of objects are removed from the object by default in the app/v1 version of apiVersion.

Example of backend cascading deletion:

Kubectl proxy-port=8080

Curl-X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset\

-d'{"kind": "DeleteOptions", "apiVersion": "v1", "propagationPolicy": "Background"}'\

-H "Content-Type: application/json"

Note that in the above example, kubectl plays the role of proxy. Call REST API directly to perform the delete operation, and pay attention to the value of its propagationPolicy.

Example of foreground cascading deletion:

Kubectl proxy-port=8080

Curl-X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset\

-d'{"kind": "DeleteOptions", "apiVersion": "v1", "propagationPolicy": "Foreground"}'\

-H "Content-Type: application/json"

Do not delete slave object example:

Kubectl proxy-port=8080

Curl-X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset\

-d'{"kind": "DeleteOptions", "apiVersion": "v1", "propagationPolicy": "Orphan"}'\

-H "Content-Type: application/json"

The kubectl command also supports cascading delete operations. Specify the "--cascade" option when executing the kubectl command, delete the slave object when its value is true, do not delete the slave object for false, and the default value is true. Examples are as follows:

Kubectl delete replicaset my-repset-cascade=false

When-- cascade is true, kubectl uses foreground cascading deletion or backstage cascading deletion, which is not mentioned in the document.

Attention points when cascading and deleting Deployment

When cascading a Deployment, the propagationPolicy in its delete request must be set to Foreground. Otherwise, the ReplicaSet created by Deployment will be cascaded, but the pod created by ReplicaSet will not be cascaded and will be orphaned.

PodManagementPolicy

Stattefulset's pod management policy has two optional values, the default is OrderedReady, and the other is Parallel. 1.7 is introduced.

As the name implies, OrderedReady: additions, deletions and changes will be done in order. For example, sequential creation: the web-0 Pod will not be started until the web-1 Pod is in the Running and Ready states.

Delete things delete one Pod at a time in the reverse order of the Pod ordinal index. Waits for the last one to be completely closed before deleting the next Pod.

Parallel: always start or terminate all Pod in parallel, out of order. You don't have to wait for those Pod to become Running and Ready or completely terminated before starting or terminating another Pod.

TolerationSeconds

TolerationSeconds is the time that pod can continue to run on node when it needs to be expelled.

Tolerations:

-effect: NoExecute

Key: node.kubernetes.io/not-ready

Operator: Exists

TolerationSeconds: 300

-effect: NoExecute

Key: node.kubernetes.io/unreachable

Operator: Exists

TolerationSeconds: 300lastTransitionTime

Status:

Conditions:

-lastProbeTime: null

LastTransitionTime: "2019-06-05T11:15:25Z"

Status: "True"

Type: Initialized

-lastProbeTime: null

LastTransitionTime: "2019-06-05T11:15:28Z"

Status: "True"

Type: Ready

-lastProbeTime: null

LastTransitionTime: "2019-06-05T11:15:28Z"

Status: "True"

Type: ContainersReady

-lastProbeTime: null

LastTransitionTime: "2019-06-05T11:15:25Z"

Status: "True"

Type: PodScheduledprogressDeadlineSeconds

Deployment has multiple states in the lifecycle. When creating a new ReplicaSet, it can be a progressing state, a complete state, or a fail to progress state.

Progressing Deployment

Kubernetes marks the Deployment that has performed one of the following tasks as progressing status:

Deployment is in the process of creating a new ReplicaSet. Deployment is expanding an existing ReplicaSet. Deployment is downsizing an existing ReplicaSet. A new pod is available.

You can use the kubectl roullout status command to monitor the progress of Deployment.

Complete Deployment

Kubernetes marks the Deployment with the following features as complete status:

Deployment is minimum available. The minimum available means that the number of replica available for Deployment equals or exceeds the expected number of replica in the Deployment policy. All replica related to the Deployment are updated to your specified version, that is, the update is complete. There is no old Pod in this Deployment.

You can use the kubectl rollout status command to see if Deployment is complete. If rollout completes successfully, kubectl rollout status returns an Exit Code with a value of 0.

$kubectl rollout status deploy/nginx

Waiting for rollout to finish: 2 of 3 updated replicas are available...

Deployment "nginx" successfully rolled out

$echo $?

0

Failed Deployment

Your Deployment may get stuck when trying to deploy a new ReplicaSet, and it will not be completed. This may be caused by the following factors:

Invalid reference unreadable probe failure image pull error insufficient scope limit program runtime configuration error

One way to detect this is to specify spec.progressDeadlineSeconds in your Deployment spec. Spec.progressDeadlineSeconds indicates how many seconds Deployment controller waits to determine (via Deployment status) that the Deployment process is stuck.

The following kubectl command sets up progressDeadlineSeconds so that controller reports after the Deployment has been stuck for 10 minutes:

$kubectl patch deployment/nginx-deployment-p'{"spec": {"progressDeadlineSeconds": 600}}'

"nginx-deployment" patched

Once the deadline has been exceeded, the Deployment controller adds a with the following attributes to the Deployment's

When the deadline is exceeded, Deployment controller adds a DeploymentCondition to the status.conditions of Deployment, which includes the following attributes:

Type=ProgressingStatus=FalseReason=ProgressDeadlineExceeded

Note: kubernetes will not do anything with a stuck Deployment except to report Reason=ProgressDeadlineExceeded status information. Higher-level coordinators can take advantage of it and act accordingly, for example, by rolling back Deployment to a previous version.

Note: if you pause a Deployment, kubernetnes will not check the deadline you specified during the pause. You can safely pause it during Deployment's rollout and then restore it, which will not trigger a state that exceeds the deadline.

RevisionHistoryLimit

Specifies how much old ReplicaSet is retained. The rest will be collected backstage as garbage. By default, all revision history is preserved. In future releases, it will be changed to 2.

Note: setting this value to 0 will cause all Deployment history to be cleared and the Deploynent can no longer be rolled back.

MinReadySeconds

The newly created Pod state is Ready for at least .spec.minReadySeconds to be considered Pod Available (Ready).

ActiveDeadlineSeconds

When the Pod of a Job finishes running, it enters the Completed state. But what if this Pod refuses to end for some reason?

In the API object of Job, there is a spec.activeDeadlineSeconds field that sets the maximum running time, such as:

Spec:

BackoffLimit: 5

ActiveDeadlineSeconds: 100

Once you run for more than 100 seconds, all Pod of this Job will be terminated. Also, you can see in the Pod status that the reason for termination is reason: DeadlineExceeded.

DnsPolicyhostNetworkprioritysecurityContext

So much for sharing the meaning of the kubernetes field in K8s. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

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.