印象大使_kubernetes学习大使容器模式

最新推荐文章于 2022-12-29 10:45:34 发布

weixin_26712591

最新推荐文章于 2022-12-29 10:45:34 发布

阅读量300

点赞数

文章标签： python 设计模式 c++

原文链接：https://medium.com/bb-tutorials-and-thoughts/kubernetes-learn-ambassador-container-pattern-bc2e1331bd3a

版权

印象大使

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 Ambassador container pattern. In this post, we will see this pattern in detail with an example project.

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

What is an ambassador Container
什么是大使容器
Other Patterns
其他样式
Example Project
示例项目
Test With Deployment Object
使用部署对象进行测试
How to Configure Resource Limits
如何配置资源限制
When should we use this pattern
我们什么时候应该使用这种模式
Summary
概要
Conclusion
结论

什么是大使容器？(What is an ambassador Container?)

The Ambassador container is a special type of sidecar container which simplifies accessing services outside the Pod. When you are running applications on kubernetes it’s a high chance that you should access the data from the external services. The Ambassador container hides the complexity and provides the uniform interface to access these external services.

大使箱是一种特殊的边车箱，可简化Pod外部的访问服务。在kubernetes上运行应用程序时，很有可能应该从外部服务访问数据。大使容器隐藏了复杂性，并提供了统一的接口来访问这些外部服务。

Imagine that you have the pod with one container running successfully but, you need to access external services. But, these external services are dynamic in nature or difficult to access. Sometimes there is a different format that external service returns. There are some other reasons as well and you don’t want to handle this complexity in the main container. So, we use the Ambassador containers to handle these kinds of scenarios.

想象一下，您的Pod已成功运行了一个容器，但是您需要访问外部服务。但是，这些外部服务本质上是动态的或难以访问。有时，外部服务会返回不同的格式。还有其他一些原因，您也不想在主容器中处理这种复杂性。因此，我们使用Ambassador容器来处理此类情况。

One more thing we need to notice in 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 ambassador 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工作负载

示例项目(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-ambassador-container-pattern.git

For simplicity, Imagine you have the public REST API and you have a main container that needs this data but you don’t want to handle calling this API so you have to use the Ambassador container which handles this for the main container. With this approach, your main container doesn’t need to have all the external service details. Let’s take a mock public API here https://api.mocki.io/v1/b043df5a which returns the following JSON response

为简单起见，假设您有公共的REST API，并且有一个需要此数据的主容器，但您不想处理调用此API的操作，因此必须使用Ambassador容器为主容器处理该数据。通过这种方法，您的主容器不需要具有所有外部服务详细信息。让我们在这里使用模拟的公共API https://api.mocki.io/v1/b043df5a ，该API返回以下JSON响应

大使箱(Ambassador Container)

Let’s look at the Ambassador container which is a simple NGINX server that acts as a reverse proxy. Here is the simple nginx.conf file.

让我们看一下Ambassador容器，它是一个简单的NGINX服务器，用作反向代理。这是简单的nginx.conf文件。

worker_processes 4;


events { worker_connections 1024; }


http {
    server {
        listen 3000;
        location / {
            proxy_pass http://api.mocki.io/v1/b043df5a;
        }
    }
}

Here is the Dockerfile that builds the image.

这是构建映像的Dockerfile。

FROM nginx:alpine


#!/bin/sh


COPY ./.nginx/nginx.conf /etc/nginx/nginx.conf


## Remove default nginx index page
RUN rm -rf /usr/share/nginx/html/*


EXPOSE 3000


ENTRYPOINT ["nginx", "-g", "daemon off;"]

Let’s build this image and push it to Docker Hub.

让我们构建此映像并将其推送到Docker Hub。

// build the image
docker build -t nginx-server-proxy .// tag the image
docker tag nginx-server-proxy bbachin1/nginx-server-proxy// push the image
docker push bbachin1/nginx-server-proxy

主箱 (Main Container)

The main container is the nodejs express server that serves on the port 9000. This server calls the reverse proxy and this proxy intern calls the actual API. Here is the server.js file.

主容器是在端口9000上使用的nodejs express服务器。该服务器调用反向代理，而该代理实习生调用实际的API。这是server.js文件。

const express = require("express");
const app = express();
const port = 9000;
var rp = require('request-promise');


var options = {
    method: 'GET',
    uri: 'http://localhost:3000'
}


app.get("/", (req, res) => {
    rp(options).then(function (body) {
        res.json(JSON.parse(body))
    }).catch(function (err) {
        console.log(err);
    });
})


app.listen(port, () => {
    console.log('Server listening on port ', port);
})

Here is the Dockerfile that builds the image.

这是构建映像的Dockerfile。

FROM node:slim


COPY ./package.json .


RUN npm install


COPY ./server.js .


CMD ["node", "server.js"]

Let’s build this image and push it to Docker Hub.

让我们构建此映像并将其推送到Docker Hub。

// build the image
docker build -t main-container .// tag the image
docker tag main-container bbachin1/main-container// push the image
docker push bbachin1/main-container

Here are the two images in the DockerHub.

这是DockerHub中的两个映像。

Now the both Docker images are ready let's create a Pod with Ambassador container pattern with nginx-server-proxy acts as an ambassador container here which hides the complexity or details of the external services. The main container access the API as it is communicating on the same network since all the containers in the pod share the localhost and port space. Here is the pod.yml file.

现在，两个Docker映像都已准备就绪，让我们创建一个带有Ambassador容器模式的Pod，其中nginx-server-proxy充当大使容器，在其中隐藏了外部服务的复杂性或细节。由于Pod中的所有容器共享本地主机和端口空间，因此主容器访问API时将在同一网络上进行通信。这是pod.yml文件。

apiVersion: v1
kind: Pod
metadata:
  name: ambassador-container-demo
spec:
  containers:
  - image: bbachin1/main-container
    name: main-container
    imagePullPolicy: Always
    resources: {}
    ports:
      - containerPort: 9000
  - image: bbachin1/nginx-server-proxy
    name: ambassador-container
    imagePullPolicy: Always
    resources: {}
    ports:
      - containerPort: 3000
  dnsPolicy: Default

// create the pod
kubectl create -f pod.yml// list the pods
kubectl get po// exec into pod
kubectl exec -it ambassador-container-demo -c ambassador-container -- /bin/sh
# curl localhost:9000

You can install curl and query the localhost:9000 and check the response. Notice that the main container is running on the port 9000.

您可以安装curl并查询localhost：9000并检查响应。请注意，主容器在端口9000上运行。

使用部署对象进行测试(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 9000 based on the selectors. You will see that in action in a while.

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

Let’s look at the below deployment object where we define one main container and one ambassador container. All the containers run in parallel. The main container is running on port 9000 which maps to the outside world through the service NodePort 31953. The main container internally calls the Ambassador container running on 3000 that actually calls the external endpoint.

让我们看一下下面的部署对象，其中定义了一个主容器和一个大使容器。所有容器并行运行。主容器运行在端口9000上，该端口通过服务NodePort 31953映射到外部。主容器内部调用在3000上运行的Ambassador容器，该容器实际上调用了外部端点。

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: node-server
  name: node-server
spec:
  replicas: 5
  selector:
    matchLabels:
      app: node-server
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: node-server
    spec:
      containers:
      - image: bbachin1/main-container
        name: main-container
        imagePullPolicy: Always
        resources: {}
        ports:
          - containerPort: 9000
      - image: bbachin1/nginx-server-proxy
        name: ambassador-container
        imagePullPolicy: Always
        resources: {}
        ports:
          - containerPort: 3000
      dnsPolicy: Default
status: {}


---


apiVersion: v1
kind: Service
metadata:
  name: node-server
  labels:
    run: node-server
spec:
  ports:
  - port: 9000
    protocol: TCP
  selector:
    app: node-server
  type: NodePort

Let’s follow these commands to test the deployment.

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

// create a deployment
kubectl create -f manifest.yml// list the deployment, pods, and service
kubectl get deploy -o wide
kubectl get po -o wide
kubectl get svc -o wide

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

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

http://192.168.64.2:31953/

You can even test the pod with the following commands

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

// exec into main container of the pod
kubectl exec -it ambassador-container-demo -c ambassador-container -- /bin/sh# curl localhost:9000

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

Configuring resource limits is very important when it comes to Ambassador 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 ambassador 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 hide the complexity from the main container such as service discovery.
每当您想从主容器中隐藏复杂性时，例如服务发现。
Whenever your containerized services want to talk to external services you can use this pattern to handle the request and response for these services.
每当您的容器化服务想要与外部服务对话时，都可以使用此模式来处理这些服务的请求和响应。
Whenever there is a need to convert or standardize the format of external services responses.
每当需要转换或标准化外部服务响应的格式时。

概要 (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 Ambassador container pattern is a specialization of sidecar containers.
大使集装箱模式是一种专用的边车集装箱。
Ambassador containers run in parallel with the main container. So that you need to consider resource limits of ambassador containers while defining request/resource limits for the pod.
大使箱与主箱平行运行。因此，在定义Pod的请求/资源限制时，您需要考虑大使容器的资源限制。
The application containers and Ambassador 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.
应用程序容器和Ambassador容器并行运行，这意味着所有容器都同时运行。因此，您需要在定义容器的请求/资源限制时总结容器的所有请求/资源限制。
You should configure health checks for Ambassador containers as main containers to make sure they are healthy.
您应该将Ambassador容器配置为主要容器的运行状况检查，以确保它们是健康的。
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 you want to hide the complexity such as service discovery from the main container.
您可以在想要从主容器中隐藏诸如服务发现之类的复杂性的地方使用此模式。

结论 (Conclusion)

It’s always to good to know already proven kubernetes patterns. Make sure all your Ambassador 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 Ambassador containers are also healthy by configuring health checks.

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

翻译自: https://medium.com/bb-tutorials-and-thoughts/kubernetes-learn-ambassador-container-pattern-bc2e1331bd3a

印象大使

weixin_26712591

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
印象大使_kubernetes学习大使容器模式

印象大使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 applic...
复制链接

扫一扫