一、k8s设计-多容器pod设计模式
对于Kubernetes中的特定目的，多容器Pod非常有用。虽然并非总是需要将多个容器组合到单个Pod中，但是了解采用的正确模式会创建更强大的Kubernetes部署。
什么时候应该将多个容器合并到一个Pod中？
当容器具有完全相同的生命周期，或者容器必须在同一节点上运行时。最常见的情况是，您需要在一个与主容器相同的节点上定位和管理一个助手进程。
将容器组合到单个容器中的另一个原因是容器中容器之间的通信更加简单。这些容器可以通过共享卷（写入共享文件或目录）和进程间通信（信号或共享内存）进行通信。
有三种常见的设计模式和用例，用于将多个容器组合到一个容器中。我们将逐步介绍边车模式，适配器模式和大使模式。
边车模式
边车模式由一个主应用程序（即Web应用程序）以及一个辅助容器组成，该容器对您的应用程序是必不可少的，但不一定是应用程序本身的一部分。
最常见的Sidecar容器是日志记录实用程序，同步服务，观察程序和监视代理。在应用程序本身不运行时运行日志记录容器是没有意义的，因此我们创建了一个包含主应用程序和sidecar容器的pod。进行日志记录工作的另一个好处是，如果日志记录代码有错误，则错误将被隔离到该容器中-非必需的日志记录代码中引发的异常不会导致主应用程序崩溃。
适配器模式
适配器模式用于标准化和规范化应用程序输出或监视数据以进行聚合。
作为一个简单的示例，我们有一个跟踪响应时间的集群级监视代理。假设我们的集群中有一个Ruby应用程序，它以格式写入请求计时[DATE] - [HOST] - [DURATION]，而另一个Node.js应用程序以写入相同的信息[HOST] - [START_DATE] - [END_DATE]。
监视代理只能接受格式为的输出[RUBY|NODE] - [HOST] - [DATE] - [DURATION]。我们可以强制应用程序以所需的格式编写输出，但这会给应用程序开发人员带来负担，并且取决于此格式，可能还有其他事情。更好的替代方法是提供将输出调整为所需格式的适配器容器。然后，应用程序开发人员可以简单地更新pod定义以添加适配器容器，并且他们可以免费获得此监视。
大使模式
大使模式是将容器与外界连接的一种有用方法。大使容器本质上是一种代理，它允许其他容器连接到本地主机上的端口，而大使容器则可以根据群集的需要将这些连接代理到不同的环境。
大使模式的最佳用例之一是提供对数据库的访问。在本地进行开发时，您可能希望使用本地数据库，而测试和生产部署又需要不同的数据库。
管理连接到哪个数据库可以通过环境变量来完成，但这将意味着您的应用程序根据环境更改连接URL。更好的解决方案是使应用程序始终连接到localhost，并将映射到正确数据库的连接的责任落在大使容器上。或者，大使可以将请求发送到数据库的不同分片-应用程序本身无需担心。
二、边车模式详细讲解
Pod/Pod控制器
Pod是K8s中能被运行的最小逻辑单元，1个Pod里可以运行多个容器，他们共享UTS+NET+IPC名称
可以把Pod理解为豌豆荚，而同一Pod内的每个容器是一颗颗豌豆
一个Pod运行多个容器，又叫边车(SideCar)模式
Pod控制器是Pod启动的一种模版，用来保证在K8s里启动的Pod，应始终按照人们的预期运行(副本数，生命周期，健康状态查询)
K8s提供了众多Pod控制器，常用的有以下几种：
Deployment
DaemonSet
ReplicaSet
StatefulSet
Job
Cronjob
Name/Namespace
Name:
由于K8S内部，使用“资源”来定义每一个逻辑概念(功能)，故每种“资源”都应该有自己的“名称”
资源有api版本(apiVersion) 类别(kind),元数据(metadata)，定义清单(spec)，状态(status)等配置信息
“名称”通常定义在“资源”的"元数据"信息中
Namespace:
随着项目增多，人员增加，集群规模的扩大，需要一种能隔离K8S内各种"资源"的方法,这就是名称空间
名称空间可以理解为K8S内部的虚拟集群组
不同名称空间内的“资源”，名称可以相同，相同名称空间内的同种"资源"，“名称”不能相同
合理的使用K8S的名称空间，使得集群管理员能够更好的对交付到K8S里的服务进行分类管理和浏览
K8S默认存在的名称空间有：default，kube-system,kube-public
查询K8S里特定“资源”要带上相应的命名空间
Lable/Lable选择器
标签是k8s特色的管理方式，便于分类管理资源对象
一个标签可以对于多个资源，一个资源可以有多个标签，他们是多对多的关系
一个资源拥有多个标签，可以实现不同维度的管理
标签的组成 ：key=value
与标签类似的，还有一种“注解”(annotations)
Label选择器：
给资源打上标签后，可以使用标签选择器过滤指定的标签
标签选择器目前有两个：基于等值关系(等于，不等于)和基于集合关系(属于，不属于，存在)
许多资源支持内嵌标签选择器字段
mathcLables
matchExpressions
Service/Ingress
Service
在K8S的世界里，虽然每个Pod都会分配一个单独的IP地址，但这个IP地址会随着Pod的销毁而消失
Service(服务)就是用来解决这个问题的核心概念
一个Service可以看作一组提供相同服务的Pod对外访问接口
Service作用于哪些Pod是通过标签选择器来定义的
Ingress
Ingress是K8S急群众工作在OSI网络参考模型下，第7层的应用，对外暴露的接口
Service只能进行L4流量调度，表现形式为ip+port
Ingress则可以调度不同业务域，不同URL访问路径的业务流量
核心组件：
配置存储中心 --->etcd服务
主控节点
kube-apiserver 服务
提供集群管理的RESTAPI接口(包括鉴权，数据校验及集群状态变更)
负责其他模块之间的数据交互，承担通信枢纽功能
是资源配额控制的入口
提供完备的集群安全机制
kube-controller-manager服务
由一系列控制器组成，通过apiserver监控整个集群的状态，并确保集群处于预期的工作状态
Node Controller
Deplyment Controller
Service Controller
。。。。
kube-scheduler服务
主要功能是接收调度pod到合适的运算节点上
预算策略(predict)
优选策略(priorties)
运算(node)节点
kube-kubelet服务
简单的说，kubelet的主要功能就是定时从某个地方获取节点上pod的期望状态（运行什么容器，运行的副本数量，网络或者存储如何配置等等），并调用相应的容器平台接口达到这个状态
定时汇报当前节点的状态给apiserver ，以供调度的时候使用
镜像和容器的清理功能工作，保证节点上镜像不会占满磁盘空间，退出的容器不会占用太多资源
kube-proxy服务
是K8s在每个节点上运行网络代理，service资源的载体
建立了pod网络和集群网络的关系(clusterip-->podip)
常用三种流量调度模式
Uerspace(废弃)
Iptables(临时废弃)
Ipvs(推荐)
负责建立和删除包括更新调度规则，通知apiserver自己的更新，或者从apiserver那里获取其他kube-proxy的调度规则裱花来更新自己的
CLI客户端
kubectl
核心附件：
CNI网络插件 ->flannel/calico
服务发现用插件 ->coredns
服务暴露用插件 ->traefik
GUI管理插件 ->Dashboard
三、Kubernetes十大必知设计模式
以下是由「Kubernetes patterns」一书综合而成的初学者必须知道的十大设计模式。熟悉这些模式将帮助您理解基本的Kubernetes概念，从而在讨论和设计基于Kubernetes的应用程序时帮助到您。
Kubernetes中有很多重要的概念，但理解这些设计模式是最重要的:
为了帮助您理解，受GoF设计模式的启发，下面将模式组织为以下几个类别。
基础模式 - Foundational patterns
这些模式代表了容器化应用程序必须遵守的原则和最佳实践，以便成为优秀的云原生公民。无论应用程序的性质如何，您都应该遵循以下指导原则。遵循这些原则将有助于确保您的应用程序适合于Kubernetes上的自动化。
探针检查模式
运行状况探测要求每个容器都应该实现特定的api，以帮助平台以尽可能健康的方式观察和管理应用程序。为了实现完全自动化，本地云应用程序必须具有高度可观察性，允许推断其状态，以便Kubernetes能够检测应用程序是否已启动并准备好为请求提供服务。这些观察结果会影响Pods的生命周期管理以及何时将应用程序对外提供服务。
声明式需求模式
可声明的需求解释了为什么每个容器都应该声明其资源概要文件，并将其限制在指定的资源需求中。成功的应用程序部署、管理和在共享云环境上共存的基础依赖于识别和声明应用程序的资源需求和运行时依赖关系。此模式描述您应该如何声明应用程序需求，无论它们是运行时强依赖项还是资源需求。声明您的需求对于Kubernetes在集群中为您的应用程序找到合适的位置至关重要。
自动放置模式
自动放置解释了如何影响多节点集群中的工作负载分布。放置是Kubernetes调度程序的核心功能，用于将新的pod分配给满足容器资源请求和执行调度策略的节点。该模式描述了Kubernetes调度算法的原理以及如何从外部影响内部调度决策。
结构化模式 - Structural patterns
拥有良好的云原生容器是第一步，但还不够。下一步是重用容器并将它们组合到Pod中，以实现预期的结果。这个类别中的模式关注于在Pod中构造和组织容器，以满足不同的用例。为了影响Pod中的容器导致产生了这些模式。
初始化容器设计模式 - Init Container
Init容器为与初始化相关的任务和主应用程序容器引入了一个单独的生命周期。Init容器通过与初始化相关的任务提供与主应用程序容器不同的独立生命周期，最终实现了关注点的分离。该模式引入了一个基本的Kubernetes概念，当需要初始化逻辑时，都可以使用这个设计模式。
边车模式 - Sidecar
Sidecar描述了如何在不更改现有容器的情况下扩展和增强其功能。该模式是一种基本的容器模式，允许单一用途的容器紧密合作。
行为模式 - Behavioral patterns
这些模式描述了管理平台确保了Pods的生命周期。根据工作负载的类型，Pod可以作为批处理作业运行到完成为止，或者被安排定期运行。它也可以作为守护进程服务或单例运行。选择正确的生命周期管理原语将帮助您以所需的方式运行Pod。
批处理作业模式
Batch Job描述如何运行独立的原子工作单元直到完成。此模式适合于在分布式环境中管理孤立的原子工作单元。
有状态服务模式
StatefulSet描述如何使用Kubernetes创建和管理分布式有状态应用程序。这类应用程序需要诸如持久标识、网络、存储和序数等特性。StatefulSet原语为这些构建提供了强有力的保证，非常适合管理有状态应用程序。
服务发现模式
服务发现解释了客户机如何访问和发现提供应用程序服务的实例。为此，Kubernetes提供了多种机制，这取决于服务使用者和生产者是位于集群上还是集群外。
高层设计模式 - Higher-leve
这个类别中的模式更复杂，代表更高级别的应用程序管理模式。这里的一些模式(如Controller)是永恒的，Kubernetes本身就是建立在它们之上的。
控制器模式
Controller是一种模式，它主动监视和维护一组处于所需状态的Kubernetes资源。Kubernetes的核心本身由一系列控制器组成，这些控制器定期监视并协调应用程序的当前状态与声明的目标状态。此模式描述了如何利用这个核心概念为我们自己的应用程序扩展平台。
Operator模式
Operator是一个控制器，它使用CustomResourceDefinitions将特定应用程序的操作知识封装为特定结构和自动化形式。Operator模式允许我们扩展控制器模式以获得更大的灵活性和表现力。Kubernetes的Operator越来越多，这种模式正成为操作复杂分布式系统的主要形式。
总结
如今，Kubernetes是最受欢迎的容器编排平台。它是由前沿软件公司共同开发和支持的，并由所有主要的云提供商作为服务提供。Kubernetes支持Linux和Windows系统，以及所有主要的编程语言。这个平台还可以编排和自动化无状态和有状态的应用程序、批处理作业、定期任务和无状态服务工作负载。这里描述的模式是Kubernetes提供的更广泛模式中最常用的模式，如下所示。
扫一扫
1424
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
