c++ 容器 容器适配器

重点(Top highlight)

Kubernetes is an open-source container orchestration engine for automating deployment, scaling, and management of containerized applications. A pod is the basic building block of kubernetes application. Kubernetes manages pods instead of containers and pods encapsulate containers. A pod may contain one or more containers, storage, IP addresses, and, options that govern how containers should run inside the pod.

Kubernetes是一个开源容器编排引擎，用于自动化容器化应用程序的部署，扩展和管理。 Pod是kubernetes应用程序的基本构建块。 Kubernetes管理Pod而不是容器，并且Pod封装容器。 一个Pod可能包含一个或多个容器，存储，IP地址以及控制容器在Pod中运行方式的选项。

A pod that contains one container refers to a single container pod and it is the most common kubernetes use case. A pod that contains Multiple co-related containers refers to a multi-container pod. There are few patterns for multi-container pods one of them is the adapter container pattern. In this post, we will see this pattern in detail with an example project.

包含一个容器的Pod是指单个容器Pod，这是最常见的kubernetes用例。 包含多个相互关联的容器的容器是指多容器容器。 多容器容器的模式很少，其中之一是适配器容器模式。 在这篇文章中，我们将通过一个示例项目来详细了解这种模式。

What are Adapter Containers

什么是适配器容器

Other Patterns

其他样式

Example Project

示例项目

Test With Deployment Object

使用部署对象进行测试

How to Configure Resource Limits

如何配置资源限制

When should we use this pattern

我们什么时候应该使用这种模式

Summary

概要

Conclusion

结论

什么是适配器容器(What are Adapter Containers)

There are so many applications that are heterogeneous in nature which means they don’t contain the same interface or not consistent with other systems. This pattern extends and enhances the functionality of current containers without changing it as the sidecar container pattern. Nowadays, We know that we use container technology to wrap all the dependencies for the application to run anywhere. A container does only one thing and does that thing very well.

本质上有很多应用程序是异构的，这意味着它们不包含相同的接口或与其他系统不一致。 这种模式扩展并增强了当前容器的功能，而无需将其更改为sidecar容器模式。 如今，我们知道我们使用容器技术来包装所有依赖项，以便应用程序可以在任何地方运行。 容器只做一件事情，并且做得很好。

Imagine that you have the pod with a single container working very well but, it doesn't have the same interface with other systems to integrate or work with it. How can you make this container to have a unified interface with a standardized format so that other systems can to your container? This adapter container pattern really helps exactly in that situation.

想象一下，只有一个容器的Pod可以很好地工作，但是它与其他系统没有相同的接口来集成或使用它。 如何使该容器具有标准化格式的统一接口，以便其他系统可以连接到您的容器？ 这种适配器容器模式确实可以在这种情况下提供帮助。

Adapter Container Pattern 适配器容器样式

If you look at the above diagram, you can define any number of containers for Adapter containers and your main container works along with it successfully. All the Containers will be executed parallelly and the whole functionality works only if both types of containers are running successfully. Most of the time these adapter containers are simple and small that consume fewer resources than the main container.

如果您查看上面的图，则可以为Adapter容器定义任意数量的容器，并且您的主容器可以成功地与其一起使用。 所有容器将并行执行，并且仅当两种类型的容器都成功运行时，整个功能才起作用。 大多数情况下，这些适配器容器既简单又小巧，比主容器消耗更少的资源。

其他样式 (Other Patterns)

There are other patterns that are useful for everyday kubernetes workloads

还有其他模式可用于日常的kubernetes工作负载

Init Container Pattern

初始化容器模式

Sidecar Container Pattern

边车集装箱模式

Ambassador Container Pattern

大使容器模式

示例项目(Example Project)

Here is the example project you can clone and run it on your machine. You need to install Minikube as a prerequisite.

这是示例项目，您可以克隆并在计算机上运行它。 您需要先安装Minikube。

https://github.com/bbachi/k8s-adaptor-container-pattern.git

Imagine your main container generates logs in text format and external systems need to consume these logs in a JSON format. You need to have some mechanism to convert text files to JSON format.

想象一下，您的主容器以文本格式生成日志，并且外部系统需要以JSON格式使用这些日志。 您需要某种机制将文本文件转换为JSON格式。

Adapter Pattern 适配器图案

The Adapter container is a simple express node server that reads from the location /var/log/file.log and produces JSON format. Let’s implement a simple project to understand this pattern. The Adapter container is a simple express API that serves these logs as a JSON response. Here is the file server.js

适配器容器是一个简单的快速节点服务器，它从/var/log/file.log位置读取并生成JSON格式。 让我们实现一个简单的项目来理解这种模式。 适配器容器是一个简单的快速API，可将这些日志用作JSON响应。 这是文件server.js

const express = require('express'); const lineReader = require('line-reader'), Promise = require('bluebird'); const app = express(), port = 3080; const logs = [] var eachLine = Promise.promisify(lineReader.eachLine); app.get('/logs', (req,res) => { eachLine('/var/log/file.log', function(line) { console.log(line); logs.push({ time: line.split("#")[0], message: line.split("#")[1] }); }).then(function() { console.log("I'm done!!"); res.send(logs); }).then(function(err){ console.log(err); }); }); app.listen(port, () => { console.log(`Server listening on the port::${port}`); });

Here is the Dockerfile that converts this app into a Docker image.

这是将该应用程序转换为Docker映像的Dockerfile。

# base image FROM node:slim # setting the work direcotry WORKDIR /usr/src/app # copy package.json COPY ./package.json . # install dependencies RUN npm install # COPY server.js COPY ./server.js . CMD ["node","server.js"]

The following are the commands creating a Docker image and pushing into Docker Hub.

以下是创建Docker映像并将其推入Docker Hub的命令。

// build the Docker imagedocker build -t bbachin1/adapter-node-server .// list the imagesdocker images// push the imagedocker push bbachin1/adapter-node-server Docker Hub Docker集线器

Once the Docker image is ready and pushed into Docker Hub and it can be available publicly. You can pull it when creating a pod. Here is a simple pod that has a main and adapter container. The main container is busybox generating some logs to the path /var/log/file.log from the volume mount workdir location. Since the Adapter container and main container runs parallel node express API will display the new log information every time you hit in the browser.

一旦Docker映像准备就绪并推送到Docker Hub中，它便可以公开使用。 您可以在创建广告连播时将其拉出。 这是一个具有主容器和适配器容器的简单吊舱。 主容器是busybox，它从卷装载工作目录位置生成一些到/var/log/file.log路径的日志。 由于适配器容器和主容器运行并行节点，因此Express API每次在浏览器中命中都会显示新的日志信息。

apiVersion: v1 kind: Pod metadata: name: adapter-container-demo spec: containers: - image: busybox command: ["/bin/sh"] args: ["-c", "while true; do echo $(date -u)'#This is log' >> /var/log/file.log; sleep 5;done"] name: main-container resources: {} volumeMounts: - name: var-logs mountPath: /var/log - image: bbachin1/adapter-node-server name: adapter-container imagePullPolicy: Always resources: {} ports: - containerPort: 3080 volumeMounts: - name: var-logs mountPath: /var/log dnsPolicy: Default volumes: - name: var-logs emptyDir: {} // create the podkubectl create -f pod.yml// list the podskubectl get po// exec into podkubectl exec -it adapter-container-demo -c adapter-container -- /bin/sh# apt-get update && apt-get install -y curl# curl localhost

You can install curl and query the localhost and check the response.

您可以安装curl和查询localhost并检查响应。

Testing Adapter Container 测试适配器容器

使用部署对象进行测试(Test With Deployment Object)

Let’s create a deployment object with the same pod specification with 5 replicas. I have created a service with the port type NodePort so that we can access the deployment from the browser. Pods are dynamic here and the deployment controller always tries to maintain the desired state that’s why you can’t have one static IP Address to access the pods so that you have to create a service that exposes the static port to the outside world. Internally service maps to the port 3080 based on the selectors. You will see that in action in a while.

让我们创建具有5个副本的相同pod规范的部署对象。 我已经创建了端口类型为NodePort的服务，以便我们可以从浏览器访问部署。 Pod在这里是动态的，并且部署控制器始终尝试保持所需的状态，这就是为什么您不能使用一个静态IP地址来访问Pod的原因，因此必须创建一个将静态端口暴露给外界的服务。 内部服务根据选择器映射到端口3080 。 您会在一段时间内看到它的作用。

Deployment 部署方式

Let’s look at the below deployment object where we define one main container and one adapter container. All the containers run in parallel. The main container creates logs in the location /var/log/file.log. The adapter container serves those log files in a JSON format on the REST API on the port 3080. You will see that in action in a while.

让我们看一下下面的部署对象，其中定义了一个主容器和一个适配器容器。 所有容器并行运行。 主容器在/var/log/file.log位置中创建日志。 适配器容器在端口3080上的REST API上以JSON格式提供这些日志文件。 您会在一段时间内看到它的作用。

apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: app: node-webapp name: node-webapp spec: replicas: 5 selector: matchLabels: app: node-webapp strategy: {} template: metadata: creationTimestamp: null labels: app: node-webapp spec: containers: - image: busybox command: ["/bin/sh"] args: ["-c", "while true; do echo $(date -u)'#This is log' >> /var/log/file.log; sleep 5;done"] name: main-container resources: {} volumeMounts: - name: var-logs mountPath: /var/log - image: bbachin1/adapter-node-server name: adapter-container imagePullPolicy: Always resources: {} ports: - containerPort: 3080 volumeMounts: - name: var-logs mountPath: /var/log dnsPolicy: Default volumes: - name: var-logs emptyDir: {} status: {} --- apiVersion: v1 kind: Service metadata: name: node-webapp labels: run: node-webapp spec: ports: - port: 3080 protocol: TCP selector: app: node-webapp type: NodePort

Let’s follow these commands to test the deployment.

让我们按照以下命令测试部署。

// create a deploymentkubectl create -f manifest.yml// list the deployment, pods, and servicekubectl get deploy -o widekubectl get po -o widekubectl get svc -o wide deployment in action 实际部署

In the above diagram, You can see 5 pods running in different IP addresses and the service object maps the port 32063 to the port 3080. You can actually access this deployment from the browser from the kubernetes master IP address 192.168.64.2 and the service port 32063.

在上图中，您可以看到5个Pod在不同的IP地址中运行，服务对象将端口32063映射到端口30 80 。 实际上，您可以从浏览器通过kubernetes主IP地址192.168.64.2和服务端口32063访问此部署。

http://192.168.64.2:32063/logs Adapter container pattern 适配器容器样式

You can even test the pod with the following commands

您甚至可以使用以下命令测试广告连播

// exec into main container of the podkubectl exec -it <pod name> -c adapter-container -- /bin/sh// install curl# apt-get update && apt-get install -y curl# curl localhost

如何配置资源限制 (How to Configure Resource Limits)

Configuring resource limits is very important when it comes to Adapter containers. The main point we need to understand here is All the containers run in parallel so when you configure resource limits for the pod you have to take that into consideration.

对于适配器容器，配置资源限制非常重要。 我们在这里需要了解的要点是所有容器都是并行运行的，因此在为容器配置资源限制时，必须考虑到这一点。

The sum of all the resource limits of the main containers as well as adapter containers (Since all the containers run in parallel)

主容器和适配器容器的所有资源限制的总和(因为所有容器并行运行)

我们什么时候应该使用这种模式？ (When should we use this pattern?)

These are some of the scenarios where you can use this pattern

在某些情况下，您可以使用此模式

Whenever you want to extend the functionality of the existing single container pod without touching the existing one.

每当您想扩展现有单个容器吊舱的功能而无需接触现有容器吊舱时。Whenever you want to enhance the functionality of the existing single container pod without touching the existing one.

每当您想增强现有单个容器容器的功能而又不触及现有容器容器的情况时。 Whenever there is a need to convert or standardize the format for the rest of the systems.

每当需要转换或标准化其余系统的格式时。

概要 (Summary)

A pod that contains one container refers to a single container pod and it is the most common kubernetes use case.

包含一个容器的Pod是指单个容器Pod，这是最常见的kubernetes用例。A pod that contains Multiple co-related containers refers to a multi-container pod.

包含多个相互关联的容器的容器是指多容器容器。 The Adapter container pattern is a specialization of sidecar containers.

Adapter容器模式是Sidecar容器的一种特殊化。 Adapter containers run in parallel with the main container. So that you need to consider the resource limits of adaptor containers while defining request/resource limits for the pod.

适配器容器与主容器并行运行。 因此，在定义Pod的请求/资源限制时，您需要考虑适配器容器的资源限制。 The application containers and Adapter containers run-in parallel which means all the containers run at the same time. So that you need to sum up all the request/resource limits of the containers while defining request/resource limits for the pod.

应用程序容器和适配器容器并行运行，这意味着所有容器都同时运行。 因此，您需要在定义容器的请求/资源限制时总结容器的所有请求/资源限制。 You should configure health checks for Adapter containers as main containers to make sure they are healthy.

您应该将适配器容器作为主要容器配置运行状况检查，以确保它们是健康的。 All the pods in the deployment object don’t have static IP addresses so that you need a service object to expose to the outside world.

部署对象中的所有Pod没有静态IP地址，因此您需要一个服务对象才能向外界公开。 The service object internally maps to the port container port based on the selectors.

服务对象根据选择器在内部映射到端口容器端口。 You can use this pattern where your application or main containers need to standardize some format for the external systems.

您可以在应用程序或主容器需要为外部系统标准化某种格式的地方使用此模式。

结论 (Conclusion)

It’s always to good to know already proven kubernetes patterns. Make sure all your adapter containers are simple and small enough because you have to sum up all the resources/request limits while defining resource limits for the pod. You need to make sure Adapter containers are also healthy by configuring health checks.

知道已经证明的kubernetes模式总是很高兴。 确保所有适配器容器都足够简单且足够小，因为在定义Pod的资源限制时必须总结所有资源/请求限制。 您需要通过配置运行状况检查来确保适配器容器也正常。

翻译自: https://medium.com/bb-tutorials-and-thoughts/kubernetes-learn-adaptor-container-pattern-97674285983c

c++ 容器 容器适配器