init模式
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 on of them is the init container pattern. In this post, we will see this pattern in detail with an example project.
包含一个容器的Pod是指单个容器Pod，这是最常见的kubernetes用例。 包含多个相互关联的容器的容器是指多容器容器。 init容器模式几乎没有用于多容器容器的模式。 在这篇文章中，我们将通过一个示例项目来详细了解这种模式。
What are Init Containers
什么是初始化容器
Example Project
示例项目
Test With Deployment Object
使用部署对象进行测试
How to Configure Resource Limits
如何配置资源限制
When should we use this pattern
我们什么时候应该使用这种模式
Summary
摘要
Conclusion
结论
什么是初始化容器 (What are Init Containers)
Init Containers are the containers that should run and complete before the startup of the main container in the pod. It provides a separate lifecycle for the initialization so that it enables separation of concerns in the applications. For example, you need to install some specific software before you want to run your application you can do that installation part in the Init Container of the pod.
初始化容器是在容器中启动主容器之前应运行并完成的容器。 它为初始化提供了单独的生命周期，因此可以分离应用程序中的关注点。 例如，您需要安装一些特定的软件，然后才能运行应用程序，然后可以在Pod的Init容器中进行安装。
If you look at the above diagram, you can define n number of containers for Init containers and your main container starts only after all the Init containers are terminated successfully. All the init Containers will be executed sequentially and if there is an error in the Init container the pod will be restarted which means all the Init containers are executed again. So, it's better to design your Init container as simple, quick, and Idompodent.
如果您查看上图，则可以为Init容器定义n个容器，并且只有在所有Init容器都成功终止之后，主容器才会启动。 所有init容器将顺序执行，如果init容器中有错误，则pod将重新启动，这意味着将再次执行所有init容器。 因此，最好将Init容器设计为简单，快速且具有Idompodent功能。
示例项目 (Example Project)
Let’s implement a simple project to understand this pattern. Here is a simple pod that has main and init containers. The main container is nginx serving on the port 80 that takes the index.html from the volume mount workdir location. The init container with the image busybox will create the file at the same location. Since the Init container is run first and terminated before the start of the main container Nginx will find the file at the location /usr/share/nginx/html.
让我们实现一个简单的项目来理解这种模式。 这是一个具有主容器和初始化容器的简单吊舱。 主要容器是nginx，它在端口80上提供服务，该端口从卷装载工作目录位置获取index.html。 带有图像busybox的初始化容器将在同一位置创建文件。 由于Init容器首先运行并在主容器启动之前终止，因此Nginx将在/ usr / share / nginx / html位置找到该文件。
apiVersion: v1
kind: Pod
metadata:
name: init-container-demo
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: workdir
mountPath: /usr/share/nginx/html
# These containers are run during pod initialization
initContainers:
- name: busybox
image: busybox
command: ["/bin/sh"]
args: ["-c", "echo 'Hi I am from Init container
' >> /work-dir/index.html"]
volumeMounts:
- name: workdir
mountPath: "/work-dir"
dnsPolicy: Default
volumes:
- name: workdir
emptyDir: {}Let’s run the following commands to create the pod and test it out.
让我们运行以下命令来创建Pod并对其进行测试。
// create the pod
kubectl create -f pod.yml// list the pods
kubectl get po// exec into pod
kubectl exec -it init-container-demo -- /bin/sh
# apt-get update && apt-get install -y curl
# curl localhostYou can install curl and query the localhost and check the response.
您可以安装curl和查询localhost并检查响应。
使用部署对象进行测试 (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 80 based on the selectors. You will see that in action in a while.
让我们创建具有5个副本的相同pod规范的部署对象。 我已经创建了端口类型为NodePort的服务，以便我们可以从浏览器访问部署。 Pod在这里是动态的，并且部署控制器始终尝试保持所需的状态，这就是为什么您无法使用一个静态IP地址来访问Pod的原因，因此必须创建一个将静态端口暴露给外界的服务。 内部服务根据选择器映射到端口80。 您会在一段时间内看到它的作用。
Let’s look at the below deployment object where we define two init containers. Init containers run sequentially the first init container writes this line “ Hi I am from second Init containerHi I am from Init container
” and the second container appends this line “
让我们看一下下面的部署对象，其中定义了两个初始化容器。 Init容器按顺序运行，第一个Init容器写此行“ Hi，我来自第二个Init容器 ” Hi，我来自Init容器”
，第二个容器附加此行“
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: nginx-webapp
name: nginx-webapp
spec:
replicas: 5
selector:
matchLabels:
app: nginx-webapp
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: nginx-webapp
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: workdir
mountPath: /usr/share/nginx/html
# These containers are run during pod initialization
initContainers:
- name: busybox1
image: busybox
command: ["/bin/sh"]
args: ["-c", "echo 'Hi I am from Init container
' >> /work-dir/index.html"]
volumeMounts:
- name: workdir
mountPath: "/work-dir"
- name: busybox2
image: busybox
command: ["/bin/sh"]
args: ["-c", "echo 'Hi I am from second Init container
' >> /work-dir/index.html"]
volumeMounts:
- name: workdir
mountPath: "/work-dir"
dnsPolicy: Default
volumes:
- name: workdir
emptyDir: {}
status: {}
---
apiVersion: v1
kind: Service
metadata:
name: nginx-webapp
labels:
run: nginx-webapp
spec:
ports:
- port: 80
protocol: TCP
selector:
app: nginx-webapp
type: NodePortLet’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 wideIn the above diagram, You can see 5 pods running in different IP addresses and the service object maps the port 32244 to the port 80. You can actually access this deployment from the browser from the kubernetes master IP address 192.168.64.2 and the service port 32244.
在上图中，您可以看到5个Pod在不同的IP地址中运行，并且服务对象将端口32244映射到端口80。您实际上可以从浏览器中从kubernetes主IP地址192.168.64.2和服务端口访问此部署。 32244 。
http://192.168.64.2:32244如何配置资源限制 (How to Configure Resource Limits)
Configuring resource limits is very important when it comes to Init containers. The main point we need to understand here is Init containers run first before the start of the main container so when you configure resource limits for the pod you have to take that into consideration.
对于Init容器，配置资源限制非常重要。 我们需要在这里理解的要点是Init容器在主容器启动之前首先运行，因此，当您为Pod配置资源限制时，必须考虑到这一点。
- The highest init container resource limits (since Init containers run sequentially) 最高的初始化容器资源限制(因为初始化容器按顺序运行)
- The sum of all the resource limits of the main containers (Since all the application containers run in parallel) 主容器的所有资源限制的总和(因为所有应用程序容器并行运行)
我们什么时候应该使用这种模式 (When should we use this pattern)
These are some of the scenarios where you can use this pattern
在某些情况下，您可以使用此模式
- You can use this pattern where your application or main containers need some prerequisites such as installing some software, database setup, permissions on the file system before starting. 您可以在应用程序或主容器需要一些先决条件(例如在启动之前安装一些软件，数据库设置，文件系统的权限)时使用此模式。
- You can use this pattern where you want to delay the start of the main containers. 您可以在想要延迟主容器启动的地方使用此模式。
摘要 (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 Init container pattern is one of the patterns that we use regularly for initialization tasks. 初始化容器模式是我们经常用于初始化任务的模式之一。
- Init containers run sequentially which means one by one. So that you need to consider using the highest resource limit while defining request/resource limits for the pod. 初始化容器按顺序运行，这意味着一个接一个。 因此，在定义Pod的请求/资源限制时，您需要考虑使用最高的资源限制。
- The application containers run-in parallel which means all the application containers runs 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. 应用程序容器并行运行，这意味着所有应用程序容器都同时运行。 因此，您需要在定义容器的请求/资源限制时总结容器的所有请求/资源限制。
- 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 some prerequisites such as installing some software, database setup, permissions on the file system before starting. 您可以在应用程序或主容器需要一些先决条件(例如在启动之前安装一些软件，数据库设置，文件系统的权限)时使用此模式。
结论 (Conclusion)
It’s always to good to know already proven kubernetes patterns. Use this pattern whenever there are initialization tasks you need to perform and you want to have a separation of concerns. Always remember Init containers runs sequentially and should terminate first before the start of the main containers.
知道已经证明的kubernetes模式总是很高兴。 每当需要执行初始化任务并且希望将关注点分离时，请使用此模式。 切记Init容器按顺序运行，应在主容器启动之前先终止。
翻译自: https://medium.com/bb-tutorials-and-thoughts/kubernetes-learn-init-container-pattern-7a757742de6b
init模式