Use the correct posture of Kubernetes 1.2.0

Editor's note: Before we introduced the new features of kubernetes 1.2.0, it's unclear about the children's shoes here .

This article discusses the use of kubernetes 1.2.0 considerations, including requirements for peripheral components (such as docker compatibility), currently known bugs (kubernetes and docker 1.9) and how to smoothly upgrade.

Part I Upgrade Notes

1. Use kubernetes 1.2.0 to recommend Docker v1.9.1, but still support v1.8.3 and v1.10. If you are using a Docker version too low, please upgrade the Docker first. But Docker v1.9.1 there are some problems, we discussed below in detail.

2. If the CPU supports CPU hardcapping and the CPU limit is set, the CPU hardcapping option is enabled by default. You can avoid hardcapping by adjusting the CPU limit or by setting the CPU request. If the kernel does not support CPU Quota, NodeStatus will contain a "Can not use CPU limit" warning.

3. This note applies only when you use the Go language client (/ pkg / client / unversioned) to create a job, such as "".Job" to define the GO variable. This is not commonly used, if you do not understand what is discussed here, then you do not have to pay attention to this issue. If you use the Go language client to create a job and republish "", you need to set job.Spec.ManualSelector = true, or set job.Spec.Selector = nil. Otherwise you create jobs that may be dismissed, the specific actions click here to view.

4.Deployment (apiVersion extensions / v1beta1) is an alpha version in v1.1 and is not integrated into release by default. Since we did a backward incompatible change to the API, the Deployment object created in v1.1 would not be available in v1.2. Specific changes are as follows:

A) Before upgrading to v1.2, be sure to remove all Alpha version of the Deployment resource, including the Deployment Control ReplicationController and Pod. After upgrading to v1.2, create the Beta version of the Deployment resource. Do not delete the Deployment resource, due to changes to the selector API, may cause the deployment controller to incorrectly match and delete other pods.

B) When the Deployment-related operations are performed, the client (kubectl) and the server-side version must match (both 1.1 or 1.2).

C) API behavior changes: ①Deployment to create ReplicaSets instead of ReplicationController; ② scale subresource state structure added a field targetSelector, this field supports set-based set of selectors, but the format must be serialized results.

D) Spec changes: ① Selectors for the Deployment object are more generic (support for collection-based selectors and support for comparison-based selectors in v1.1); ②.spec.uniqueLabelKey fields have been deleted and users will not be able to Customize the unique label key, and its default value is changed from "" to "pod-template-hash"; the .spec.strategy.rollingUpdate.minReadySeconds field is replaced by .spec.minReadySeconds.

5.DaemonSet (apiVersion extensions / v1beta1) is an alpha version in v1.1 and is not included in the release by default. The DaemonSet object created in v1.1 will not be available in v1.2 because we do not have a backward incompatible change to the API. Specific changes are as follows:

A) Before upgrading to v1.2, be sure to remove all Alpha versions of DaemonSet resources. If you do not want to destroy the original Pod, you can use the command kubectl
Delete daemonset -cascade = false After upgrading to v1.2, create the Beta version of the Deployment resource.

B) For DaemonSet-related operations, the client (kubectl) and the server-side version must match (both 1.1 or 1.2).

C) API behavior changes: ① Even if the node has .spec.unschedulable = true, DaemonSet
Pod will also be created on that node, and even if the node Ready state is False, the pod will not be deleted. ② allow to update Pod
Template. If you make a rolling update on DaemonSet, you can update the pod
Template, and then delete the pod one by one, the new pod will be created according to the new pod template.

D) Spec changes: ① The selector of the DiemonSet object is more generic (supports set-based selectors and supports comparison-based selectors in v1.1).

6. If you want to run etcd in https, you need to pass the following parameters to kube-apiserver (instead of -etcd-config):

A) -etcd-certfile, –etcd-keyfile (if using client cert auth)

B) -etcd-cafile (if you do not use the system roots)

7.Kubernetes v1.2 will increase the support for protocol buffer, API will also directly support YAML format. As a preparation, in the current release, each HTTP spec Content-Type and Accept headers will be processed. So, when you send a request to the API via the client, if the Content-Type or Accept headers is invalid, you will return a 415 or 406 error. The only thing that is currently known to affect the client is curl, and the wrong thing to do is: send the JSON with -d, but do not set the Content-Type (you want to use the default "application / x-www-urlencoded"). If you are using other clients, then you need to check to confirm that the correct accept and content type headers are sent, or do not make any settings (default is JSON). Curl -H "Content-type: application / json" -XPOST -d '{"apiVersion": "v1", "kind": "Namespace", "metadata": {"name": "kube -system "}} '

8. Since the storage format of the data changes, Kubernetes requires an influxdb version of 0.9 (previously 0.8).

9. Replace the term "minions" with "nodes". If you specify NUM_MINIONS or MINION_SIZE when running kube-up, then you need to specify NUM_NODES or NODE_SIZE in 1.2.

Part II Existing problems in Kubernetes

1. The deployments in the Paused state can not be resized and will not empty the old ReplicaSets.

2. The minimum memory limit is 4MB, here is the docker limit.

3. The minimum CPU limits is 10m, here is the Linux kernel limit.

4. For paused deployments, the "kubectl rollout undo" (such as rollback) operation hangs because paused deployments can not be rolled back (the result is expected), and the command will wait for the rollback time to return the result. Before the rollback, the user should use the "kubectl rollout resume" command to restore a deployment.

5. The "kubectl edit" operation opens the editor once for each resource, so the editor will be opened many times.

6. When you create an HPA object using the autoscaling / v1 API, if you do not specify targetCPUUtilizationPercentage, reading this field with kubectl displays the default values ​​specified in extensions / v1beta1.

7. If a node carrying a storage volume or a kube bundle crashes unexpectedly, the storage volume still belongs to that node. Since a single storage volume can only be mounted on a node (such as GCE PDs mounted in RW mode), it must be manually uninstalled before it can be mounted on other nodes.

8. If a storage volume has been mounted on a node, the subsequent attempt to mount the node again (ie, because the kubelet restart) will fail. There are two workarounds, either manually uninstalling the storage volume, or deleting all associated pods, which automatically trigger the uninstall.

9. In very large clusters, at some time, there may be some nodes can not register to the API Server problem, the reasons may be varied, such as network problems, downtime and so on. Normally, when a cluster is started using the kube-up script, the kube-up will fail if any of the nodes has NotReady (even if the cluster is working properly). Here we add the variable ALLOWED_NOTREADY_NODES, which defines the maximum number of NotReady nodes allowed, that is, if the number of NotReady nodes beyond the set value, kube-up will return to failure.

10. The "kubectl rolling-update" command only supports Replication Controllers and does not support Replica Sets. If you are rolling update Replica Sets, it is recommended to use the "kubectl rollout" command in Deployment 1.2.

11. Online upgrade Kubelet to 1.2 is that if you do not empty the pods running on the node, all containers managed by the kubelet will reboot.

Part III Docker Existing Issues (v1.9.1)

1.docker ps operation is sometimes very slow, and thus affect the performance of kubelet.

2.Docker daemon restart may fail. When restarting, the docker checkpoints must be deleted.

3.Pod IP allocation related issues. Deleting the docker checkpoint before restarting the docker daemon helps alleviate the problem, but has not yet verified whether it can solve the problem altogether.

4. As the kernel deadlock, Docker daemon may be no response to the situation (rarely appear).

Heads up! This alert needs your attention, but it's not super important.