容器组_初始化容器

📕作者简介: 过去日记,致力于Java、GoLang,Rust等多种编程语言,热爱技术,喜欢游戏的博主。
📘相关专栏Rust初阶教程、go语言基础系列、spring教程等,大家有兴趣的可以看一看
📙Java并发编程系列,设计模式系列、go web开发框架 系列正在发展中,喜欢Java,GoLang,Rust,的朋友们可以关注一下哦!
容器组_初始化容器
初始化容器介绍
Pod 可以包含多个工作容器,也可以包含一个或多个初始化容器,初始化容器在工作容器启动之前执行。
初始化容器与工作容器完全相同,除了如下几点:
- 初始化容器总是运行并自动结束
- kubelet 按顺序执行 Pod 中的初始化容器,前一个初始化容器成功结束后,下一个初始化容器才开始运行。所有的初始化容器成功执行后,才开始启动工作容器
- 如果 Pod 的任意一个初始化容器执行失败,kubernetes 将反复重启该 Pod,直到初始化容器全部成功(除非 Pod 的 restartPolicy 被设定为 Never)
- 初始化容器的 Resource request / limits 处理不同,
- 初始化容器不支持 就绪检查 readiness probe,因为初始化容器必须在 Pod ready 之前运行并结束
使用初始化容器
初始化容器可以指定不同于工作容器的镜像,这使得初始化容器相较于直接在工作容器中编写启动相关的代码更有优势:
- 初始化容器可以包含工作容器中没有的工具代码或者自定义代码。例如:您无需仅仅为了少量的 setup 工作(使用 sed, awk, python 或 dig 进行环境设定)而重新从一个基础镜像制作另外一个镜像
- 初始化容器可以更安全地执行某些使工作容器变得不安全的代码
- 应用程序的镜像构建者和部署者可以各自独立地工作,而无需一起构建一个镜像
- 初始化容器相较于工作容器,可以以另外一个视角处理文件系统。例如,他们可以拥有访问 Secrets 的权限,而工作容器却不一定被授予该权限
- 初始化容器在任何工作容器启动之前结束运行,这个特性使得我们可以阻止或者延迟工作容器的启动,直到某些前提条件得到满足。一旦前提条件满足,所有的工作容器将同时并行启动
Examples
下面是一些使用初始化容器的例子:
- 使用一行 shell 命令,等待某一个 Service 启动后再启动工作容器
for i in {1…100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
- 使用 Pod 的信息将其注册到某一个远程服务:
curl -X POST http:// M A N A G E M E N T S E R V I C E H O S T : MANAGEMENT_SERVICE_HOST: MANAGEMENTSERVICEHOST:MANAGEMENT_SERVICE_PORT/register -d ‘instance=KaTeX parse error: Expected 'EOF', got '&' at position 13: (<POD_NAME>)&̲ip=(<POD_IP>)’
- 等候一定时间再启动工作容器
sleep 60
- 将 Git repository 克隆到一个数据卷
- 根据某些参数,运行一个模板工具动态生成工作容器所需要的配置文件
初始化容器的行为
- Pod 的启动时,首先初始化网络和数据卷,然后按顺序执行每一个初始化容器。任何一个初始化容器都必须成功退出,才能开始下一个初始化容器。如果某一个容器启动失败或者执行失败,kubelet 将根据 Pod 的 restartPolicy 决定是否重新启动 Pod。
- 只有所有的初始化容器全都执行成功,Pod 才能进入 ready 状态。初始化容器的端口是不能够通过 kubernetes Service 访问的。Pod 在初始化过程中处于 Pending 状态,并且同时有一个 type 为 initializing status 为 True 的 Condition
- 如果 Pod 重启,所有的初始化容器也将被重新执行。
- 您可以重启、重试、重新执行初始化容器,因此初始化容器中的代码必须是 幂等 的。具体来说,向 emptyDir 写入文件内容的代码应该考虑到该文件已经存在的情况。请参考 幂等 获得更多信息
- 您可以组合使用就绪检查和 activeDeadlineSeconds Kuboard 暂不支持,以防止初始化容器始终失败。
- Pod 中不能包含两个同名的容器(初始化容器和工作容器也不能同名)。
Resources
在确定初始化容器的执行顺序以后,以下 resource 使用规则将适用:
- 所有初始化容器中最高的 resource request/limit 是最终生效的 request/limit
- 对于 Pod 来说,最终生效的 resource request/limit 是如下几个当中较高的一个:
- 所有工作容器某一个 resource request/limit 的和
- 最终生效的初始化容器的 request/limit 的和
- Kubelet 依据最终生效的 request/limit 执行调度,这意味着,在执行初始化容器时,就已经为 Pod 申请了其资源需求
Pod 重启的原因
Pod 重启时,所有的初始化容器都会重新执行,Pod 重启的原因可能有:
- 用户更新了 Pod 的定义,并改变了初始化容器的镜像
- 改变任何一个初始化容器的镜像,将导致整个 Pod 重启
- 改变工作容器的镜像,将只重启该工作容器,而不重启 Pod
- Pod 容器基础设施被重启(例如 docker engine),这种情况不常见,通常只有 node 节点的 root 用户才可以执行此操作
- Pod 中所有容器都已经结束,restartPolicy 是 Always,且初始化容器执行的记录已经被垃圾回收,此时将重启整个 Pod
相关文章:

minikube环境搭建
📕作者简介:过去日记,致力于Java、GoLang,Rust等多种编程语言,热爱技术,喜欢游戏的博主。📘相关专栏系列、spring教程等,大家有兴趣的可以看一看📙系列,系列、系列正在发展中,喜欢Java,GoLang,Rust,的朋友们可以关注一下哦!@[TOC]# minikube## 安装### 前置条件已经安装docker### 乌班图安装科学上网是我你们安装的前提。```shell。

Pods/Nodes
Pod 容器组 是一个k8s中一个抽象的概念,用于存放一组 container,以及这些 container (容器)的一些共享资源。共享存储,称为卷(Volumes),即图上紫色圆柱网络,每个 Pod(容器组)在集群中有个唯一的 IP,pod(容器组)中的 container(容器)共享该IP地址container(容器)的基本信息,例如容器的镜像版本,对外暴露的端口等Pod(容器组)是 k8s 集群上的最基本的单元。

公布应用程序
当 worker node(节点)故障时,节点上运行的 Pod(容器组)也会消失。然后,Deployment (opens new window)可以通过创建新的 Pod(容器组)来动态地将群集调整回原来的状态,以使应用程序保持运行。举个例子,假设有一个图像处理后端程序,具有 3 个运行时副本。这 3 个副本是可以替换的(无状态应用),即使 Pod(容器组)消失并被重新创建,或者副本数由 3 增加到 5,前端系统也无需关注后端副本的变化。

伸缩应用程序和执行滚动更新
原本 Service A 将流量负载均衡到 4 个旧版本的 Pod 上2. 更新完 Deployment 部署文件中的镜像版本后,master 节点选择了一个 worker 节点,并根据新的镜像版本创建 Pod(紫色容器)。新 Pod 拥有唯一的新的 IP。同时,master 节点选择一个旧版本的 Pod 将其移除。此时,Service A 将新 Pod 纳入到负载均衡中,将旧Pod移除同步骤2,再创建一个新的 Pod 替换一个原有的 Pod。

Kubernetes对象的定义和操作
Kubernetes对象指的是Kubernetes系统的持久化实体,所有这些对象合起来,代表了你集群的实际情况。常规的应用里,我们把应用程序的数据存储在数据库中,Kubernetes将其数据以Kubernetes对象的形式通过 api server存储在 etcd 中。集群中运行了哪些容器化应用程序集群中对应用程序可用的资源应用程序相关的策略定义,例如,重启策略、升级策略、容错策略其他Kubernetes管理应用程序时所需要的信息。

名称和命名空间
📕作者简介:过去日记,致力于Java、GoLang,Rust等多种编程语言,热爱技术,喜欢游戏的博主。📘相关专栏系列、spring教程等,大家有兴趣的可以看一看📙系列,系列、系列正在发展中,喜欢Java,GoLang,Rust,的朋友们可以关注一下哦!

使用名称空间共享集群
可以限定使用某个名称空间的用户不能看到另外一个名称空间中的内容。默认情况下,安装Kubernetes集群时,会初始化一个 default 名称空间,用来将承载那些未指定名称空间的 Pod、Service、Deployment等对象。接下来,为 kubectl 定义一个上下文,以便在不同的名称空间中工作。此时,开发人员可以做任何他想要做的操作,所有操作都限定在名称空间 development 里,而无需担心影响到 production 名称空间中的内容。使用 kubectl 有两种方式可以创建名称空间。

k8s 标签和选择器
标签(Label)是附加在Kubernetes对象上的一组名值对,其意图是按照对用户有意义的方式来标识Kubernetes对象,同时,又不对Kubernetes的核心逻辑产生影响。管理这些对象时,很多时候要针对某一个维度的条件做整体操作,例如,将某个版本的程序整体删除,这种情况下,如果用户能够事先规划好标签的使用,再通过标签进行选择,就会非常地便捷。Kubernetes api server支持两种形式的标签选择器,equality-based 基于等式的 和 set-based 基于集合的。

注解annotation
Kubernetes的系统组件(例如,kube-scheduler、kube-controller-manager、kube-apiserver、kubectl 或其他第三方组件)向用户的Kubernetes对象添加注解时,必须指定一个前缀。注解(annotation)可以用来向 Kubernetes 对象的 metadata.annotations 字段添加任意的信息。除了使用注解,您也可以将这类信息存放在一个外部的数据库,然而,在使用、分享这些信息的时候,可能会变得难以管理。

字段选择器
字段选择器(Field Selector)可以用来基于的一个或多个字段的取值来选取一组Kubernetes对象。

容器组_概述
Pod(容器组)是 Kubernetes 中最小的可部署单元。一个 Pod(容器组)包含了一个应用程序容器(某些情况下是多个容器)、存储资源、一个唯一的网络 IP 地址、以及一些确定容器该如何运行的选项。Pod 容器组代表了 Kubernetes 中一个独立的应用程序运行实例,该实例可能由单个容器或者几个紧耦合在一起的容器组成。一个 Pod 中只运行一个容器。“one-container-per-pod” 是 Kubernetes 中最常见的使用方式。

容器组_生命周期
只有一种例外,那就是 Pod 处于 Scucceeded 或 Failed 的 phase,并超过了垃圾回收的时长(在 kubernetes master 中通过 terminated-pod-gc-threshold 参数指定),kubelet 自动将其删除。每一个 Pod 都有一个数组描述其是否达到某些指定的条件。Pod phase 并不是用来代表其容器的状态,也不是一个严格的状态机。Kubernetes教程:在Kuboard中配置容器的健康检查/就绪检查。Kuboard 中配置健康检查/就绪检查。

容器组_配置初始化容器
📕作者简介:过去日记,致力于Java、GoLang,Rust等多种编程语言,热爱技术,喜欢游戏的博主。📘相关专栏系列、spring教程等,大家有兴趣的可以看一看📙系列,系列、系列正在发展中,喜欢Java,GoLang,Rust,的朋友们可以关注一下哦!

Deployment概述
Pod 容器组是 Kubernetes 中最小的调度单元,更多信息请参考 容器组 - 概述Deployment 是最常用的用于部署无状态服务的方式。Deployment 控制器使得您能够以声明的方式更新 Pod(容器组)和 ReplicaSet(副本集)。以“声明”的方式管理 Pod 和 ReplicaSet,其本质是将一些特定场景的一系列运维步骤固化下来,以便快速准确无误的执行。

k8s项目部署流程
配置Kubernetes对象:您需要配置Kubernetes对象来部署应用程序。您可以使用Minikube(用于本地开发和测试)或使用云提供商如AWS、GCP等提供的Kubernetes服务。部署应用程序:使用kubectl apply命令应用Kubernetes对象,以便部署应用程序。水平伸缩:Kubernetes提供了水平伸缩功能,以便应用程序在不同的负载下自动扩展和收缩。配置域名DNS以及负载均衡:您可以使用全局负载均衡器和DNS入口来将流量路由到应用程序的服务中。