Shulou(Shulou.com)05/31 Report--

This article introduces the knowledge about "what are the new functions in Kubernetes 1.3". In the actual case operation process, many people will encounter such difficulties. Next, let Xiaobian lead you to learn how to deal with these situations! I hope you can read carefully and learn something!

New features in Kubernetes 1.3

Kubernetes 1.3 has focused on deploying and scaling services across clusters, regions and cloud boundaries, running a slightly larger range of tasks (including stateful services such as databases), increasing scale and automation, and supporting rkt, OCI&CNI container standards.

PetSet

Until now, deploying stateful applications (such as distributed databases) has been a tricky problem, but it's not impossible. Jetstack's presentation at KubeCon in London described these challenges as well as common patterns of solutions. Website: www.youtube.com/watch? v=jsTQ24CLRhI。

The community introduced the alpha version of the PetSet object to describe such a system. Kubernetes now has a feature that can be used to deploy Pods, and these Pods function to secure network and store identity. It can even dynamically provision on-demand storage in the cloud (currently available only on AWS EBS and GCE PD).

Cluster alliances ("Ubernets")

Kubernetes 1.3 enables discovery of services running on multiple clusters, possibly across regions or cloud providers for containers or external customers. This "Ubernets" consortium, which can be used to add HA, geo-distribution and hybrid/multi-cloud, is an exciting first phase and will continue to be developed and refined in versions 1.4 and beyond.

Rktnetes 1.0

Kubernetes was created without binding to a specific container runtime environment. Kubernetes version 1.3 is the first stable version of the integrated rkt runtime that can be used to replace Docker (the default runtime so far). Yes, this is rktnets.

rkt is a fast-maturing project for Core OS and is now version 1.10.0. It implements the application container specification and has many features that are perfect replacements for Docker. For example, compatibility with initialization systems (such as systemd, nspawn) ensures greater isolation (using LKVM stage1).

Learn more about rktnets from the CoreOS team in recent blogs. Website: http://blog.kubernetes.io/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes.html

scalability of

Kubernetes now supports clusters of 2000 nodes while also reducing end-to-end Pod startup time. In such cases, the challenge that ultimately resulted in scalability improvements was to use API serialization based on Protocol Buffer (https://developers.google.com/protocol-buffers/) instead of JSON.

Recent blog posts describe some of the details of the improvements, as well as the Kubemark performance testing tool used by the project. Website: http://blog.kubernetes.io/2016/07/kubernetes-updates-to-performance-and-scalability-in-1.3.html

In a few weeks or months, Jetstack will blog about these new features in more detail, and importantly, explain how to turn them on and how to put them into practice. For example, I'll show you how to handle multizone/multi-cloud using Kubernetes. We'll also show how it's easier to deploy distributed databases on-premises-in areas we're actively working with our customers on right now.

Kubernetes 1.3 Hidden New Features

In addition to the main part of this post, we want to introduce some features that we like very much, but few people know about, but these features are also useful and important. Note that some features and enhancements are still alpha versions.

Kubectl Deployment

Deployment is an API that provides declarative, server-side update pods and ReplicaSets. Although it is still a beta feature, it is now widely accepted and used, and is in active development, including planned and ongoing new features (see the roadmap for details). In Kubernetes 1.3, new commands have been added to kubectl to make it easier to manage and monitor deployment updates.

Update Deployment's container image

Previously, if you wanted to update container images for Pods in ReplicaSet, through Deployment Management, you could use kubectl and edit the YAML of Deployment directly.

New command kubectl settings now allow container mirroring to be set on a single command line.

Monitoring deployment rollout

To monitor the rollover update and verify that it succeeds, there's a handy new command: rollover status. For example, check the rollout of nginx/nginx:1.9.1 in nginx/nginx:1.7.9.

Garbage Collection (Beta)

Kubernetes resources are often interdependent. For example, ReplicaSets creates Pods from a specified template. If you want to delete this ReplicaSet, you have to find the Pods that match the selector and delete the matching Pods in tandem.

In version 1.4 and later, such tandem cleanup will be handled by KCM (kube controller manager). In preparation, 1.3 introduces an additional metadata field ownerReferences for API objects. For the ReplicaSet/Pods example, Pods contain references to their owner's ReplicaSet. Once the ReplicaSet is deleted, the garbage collector also deletes the Pod. There is also a configuration option called orphanDependents that disables tandem deletion.

Garbage collection was also an alpha feature in 1.3, so it is disabled by default. To turn this on, you need to turn on kube-apiserver and KCM, and flag--enable garbage collector.

Read more about garbage collector functionality in the user guide, and be aware that you do it at your own risk (it's a beta, after all).

Shell completion integrated into kubectl

As a veteran kubectl user, you probably already know this completion script, saved in the/contrib/completions core project folder. This provides not only the subcommands and parameters of kubectl, but also the names of resources like Namespace and Pods.

As usual, for Go binaries, the distribution of kubectl usually consists of only a single file. This makes it more difficult to preserve compatible complete files. For this reason, this script has been integrated into kubectl since version 1.3. Loading completions is now as simple as adding a line of code:

Init containers (beta)

The beta version feature init containers allows a command to be run before the release of a long-running main Pod container. These commands are executed sequentially, and only when they run successfully does the master container start running. This allows you to download specific files to a data volume, generate application configuration files, and so on without repackaging into container images.

Here is an example of Pod running a specific version of kubectl. Download this version every time a Pod is released. To demonstrate, the second init containers includes a command to execute kubectl binary. The Pod manual includes the necessary annotations, as shown below:

Once the Pod is running in state, you can run kubectl using the downloaded version 2-kubectl exec into the Pod container: )

Learn more about init containers and how to use them at http://kubernetes.io/docs/user-guide/production-pods/#handling-initialization.

Use custom configuration for pods/containers (beta)

Docker supports configuring Seccomp policies to initially restrict container execution privileges starting with version 1.10. Seccomp implements this sandbox mechanism by intercepting system calls. This filter is defined by BPF rules.

To bind a specific profile to a Pod, you can use the following alpha annotations:

Define a Seccomp for all Pod containers: seccomp.security.alpha.kubernete.io/pod

Define a Seccomp file for a single container: container.seccomp.security.alpha.kubernetes.io/${container_name}

For annotation values, you can use the following:

If you want to use custom configurations (prefixed localhost/), you must replicate these to every worker node in your cluster. The default folder for files is/var/lib/kubelet/seccomp.

Example: How to block chmod system calls

In this example, we created two Pods. try to modify permissions on the file. When Pod chmod-unconfined runs successfully with Docker's default file, the same command line fails in Pod chmod-prevented because its Seccomp file does not allow it.

To be clear, you must meet the following requirements:

Docker version 1.10 and above

Kubernetes version 1.3.0-beta.2 and above

To copy prevent-chmod to all worker nodes

Seccomp Profile/var/lib/kubelet/seccomp/prevent-chmod

Pod specification seccomp-pods.yaml

create pods

"What are the new features in Kubernetes 1.3" is introduced here. Thank you for reading. If you want to know more about industry-related knowledge, you can pay attention to the website. Xiaobian will output more high-quality practical articles for everyone!

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.