Docker 17.06 and Kubernetes 1.7: key innovations

Last week presented two “tasty” releases from the Open Source-world of containers: Docker (version 17.06) and Kubernetes (version 1.7) were updated almost simultaneously. What opportunities did they bring? The article provides information from the announcements and release notes of these releases with a few clarifications on some of the key changes.

Docker CE 17.06

June 28 was announced Docker CE (Community Edition) June 17 - the first release of the container system, assembled with the help of the project Moby , announced in April. More about Moby, we have already written .

Build in stages

The main feature of the release was the official stabilization of support for multi-stage builds (multi-stage builds), first introduced in Docker 17.05.0. Its essence lies in the ability to describe in one Dockerfile several stages of assembling an image so that intermediate data that are not required do not fall into the final image. The obvious example that Docker gives is that Java developers usually use Apache Maven to compile their applications, but Maven is not needed in the final container (image) to run these applications. Now you can arrange the Dockerfile in such a way that Maven itself will be used in the intermediate image (for assembly), but will not get into the final image (for launch).
')
Here is the Dockerfile option for a simple Java Spring Boot application :

FROM node:latest AS storefront
WORKDIR /usr/src/atsea/app/react-app
COPY react-app/package.json .
RUN npm install
COPY . /usr/src/atsea/app
RUN npm run build

FROM maven:latest AS appserver
WORKDIR /usr/src/atsea
COPY pom.xml .
RUN mvn -B -f pom.xml -s /usr/share/maven/ref/settings-docker.xml dependency:resolve
COPY . .
RUN mvn -B -s /usr/share/maven/ref/settings-docker.xml package -DskipTests

FROM java:8-jdk-alpine
WORKDIR /static
COPY --from=storefront /usr/src/atsea/app/react-app/build/ .
WORKDIR /app
COPY --from=appserver /usr/src/atsea/target/AtSea-0.0.1-SNAPSHOT.jar .
ENTRYPOINT ["java", "-jar", "/app/AtSea-0.0.1-SNAPSHOT.jar"]
CMD ["--spring.profiles.active=postgres"]

As you can see, the two preparatory stages here use Node.js and Apache Maven to build the application, but the resulting image will be compact, not having Node.js or Maven in its composition.

Note : So far in our company we have used a feature called artifacts in our own Open Source utility dapp for this purpose ( see its overview here ).

Logs and metrics

Docker metrics can now be used in plugins. For the demonstration, an example of a plugin is shown that proxies requests for a metric that is available in it:

 $ docker plugin install --grant-all-permissions cpuguy83/docker-metrics-plugin-test:latest $ curl http://127.0.0.1:19393/metrics 

But this is only a demonstration, and the real purpose of this innovation is to send the collected metrics to an external service with the help of plug-ins or make them available for assembly by another service (for example, Prometheus).

Plug-ins can now also be used for logs (that is, to implement logging drivers), and a list of all logging drivers has been added to docker info . In addition, the implementation of docker service logs , which (also from the last release on May 17, 2005) can show individual task logs ( /task/{id}/logs in REST), was transferred from the Edge branch to Stable, so it is now easy to get generalized logs for the entire service running in swarm.

Network

It became possible to link services to networks within a node (node-local): Host, Macvlan, IPVlan, Bridge, local-scope. An example for Macvlan is the creation of site-specific network configurations on the work nodes and the network on the management node, which will apply them:

 [Wrk-node1]$ docker network create --config-only --subnet=10.1.0.0/16 local-config [Wrk-node2]$ docker network create --config-only --subnet=10.2.0.0/16 local-config [Mgr-node2]$ docker network create --scope=swarm --config-from=local-config -d macvlan mynet [Mgr-node2]$ docker service create --network=mynet my_new_service 

As part of the same change, the DOCKER-USER chain was added to iptables, which is inserted first into FORWARD and is not reset (for this addition, thanks to ertaquo !) .

In addition, changes have been made to the internal algorithms of Service Discovery, which are designed to improve the logic of its work.

Swarm

A number of innovations received the Swarm mode, and in particular:

• Configuration Objects, which allow you to safely transfer configuration information in the same way as it was done for secrets:
  
  

   $ echo "This is a config" | docker config create test_config - $ docker service create --name=my-srv --config=test_config … $ docker exec -it 37d7cfdff6d5 cat test_config This is a config 

  
  
• the function of rotating CA certificates in the public key infrastructure (PKI) system used for secure deployment of the container orchestration system ( docker swarm ca --rotate );
• event support (previously available outside of Swarm) for real-time data on services, nodes, networks, secrets;
• new --datapath-addr flag for docker swarm init , indicating a network interface for isolating control traffic from application data (data traffic) - useful for applications that have a large I / O load;
• the ability to specify the storage location of the secret in the container (instead of the traditional /var/run ).

A more detailed changelog in Docker 17.06 along with links to commits can be found in Docker CE release notes . And for those who like to watch and listen, there is an 8-minute video with a story and a demonstration of the main innovations.

Kubernetes 1.7

June 29 was announced by Kubernetes 1.7 , the main innovations of which are called improvements in security, support for stateful applications, extensibility of the platform. What is behind this?

Security

• Declared stable Network Policy API , allowing you to customize the rules that define (and limit) the interaction between the sub.
• Node authorizer , which allows you to restrict kubelet API requests (to secrets, submissions and other node objects).
• The alpha version of encryption secrets and other resources stored in etcd.
• Support for certificate and client certificate rotation has been added to kubelet TLS bootstrapping .
• Audit logs, stored by the API server, have become more customizable and extensible with support for event filtering and webbooks, as well as providing more data for system auditing.

Support for stateful applications

• A beta version of the automatic StatefulSet update feature used for deploying stateful applications. The update strategy is determined by the field spec.updateStrategy , which now supports two values: OnDelete and RollingUpdate .
• Support for StatefulSets more quickly scale and launch applications that do not require a strict sequence, now configured through the Pod Management Policy . Such applications can now be launched in parallel and without waiting for the receipt of certain status (Running, Ready).
• Alpha Version of Local Storage : In StorageClasses inside StatefulSets you can now access local storage through a standard PVC / PV interface.
• Smart rollback (and change history) with DaemonSets updates.
• A new StorageOS Volume plugin that implements high-availability persistent storage volumes across the entire cluster (from local or attached storage).

Extensibility

• Aggregation API allows you to extend the capabilities of Kubernetes own API. The aggregation layer works together with kube-apiserver and does nothing until a single resource is registered for the API extension. API registration is done through an APIService object, which is implemented through an extension-apiserver inside a hearth operating in a Kubernetes cluster.
• Added new RPC calls to Container Runtime Interface (CRI) to get container metrics. Added alpha version of integration with containerd , supporting the basic life cycle of poda and image management.

Other

• Alpha version of support for external controllers Dynamic Admission , allowing you to add business logic to the API server when modifying objects.
• Alpha version of Policy-based Federated Resource Placement , which allows you to define policy-based decisions on federated resources (using an external policy engine, for example, based on price or performance requirements).
• The Third Party Resource (TPR) has been replaced by Custom Resource Definitions (CRD), which offer a “clearer API” and solve a number of problems fixed during the beta testing of TPR. Fully TPR will be removed in Kubernetes 1.8 ( migration guide is available).