Kubernetes(K8s)是一个开源的容器编排平台,用于自动化容器的部署、扩展和管理。尽管它是一个健壮的系统,但在使用中不可避免的会遇到一些故障。这些问题大致可以分为以下几类:
Longhorn 设计有两层:数据平面(data plane)和控制平面(control plane)。Longhorn Engine 是存储控制器对应数据平面,Longhorn Manager 对应控制平面。
原文: https://thenewstack.io/deleting-production-in-a-few-easy-steps-and-how-to-fix-it/
在Kubernetes(K8s)环境中部署有状态应用(Stateful Applications)涉及到一些特别的考虑和策略。有状态应用与无状态应用的主要区别在于它们需要维护数据状态,这使得它们在部署和管理上有特殊的需求。
作者:Michelle Au(谷歌),Matt Schallert(Uber),Celina Ward(Uber)
Kubernetes使用ReplicaSet来保证一个服务的实例数量,如果说某个Pod实例由于某种原因挂掉或崩溃,ReplicaSet会立刻用这个Pod的模版新启一个Pod来替代它。由于是无状态的服务,新Pod与旧Pod一模一样。此外Kubernetes通过Service(一个Service后面可以挂多个Pod)对外提供一个稳定的访问接口,实现服务的高可用。
之前有做过一个华为OBS 的CSI插件,其基本运作原理如下图所示。CSI插件Pod挂载了主机的/var/lib/kubelet/pods目录,当创建挂载Pvc的业务Pod时,CSI插件会启动一个s3fs进程,该进程用于远程连接s3服务,将bucket(也即Pvc)挂载到/var/lib/kubelet/pods中的对应Pod目录下(一般为/var/lib/kubelet/pods//volumes/kubernetes.io~csi//mount),然后由kubelet挂载到业务Pod中。
https://blog.csdn.net/hguisu/category_9999400.html
StatefulSet和Deployment的区别 “Deployment用于部署无状态服务,StatefulSet用来部署有状态服务”。 具体的,什么场景需要使用StatefulSet呢?官方给出的建议是,如果你部署的应用满足以下一个或多个部署需求,则建议使用StatefulSet。 稳定的、唯一的网络标识。 稳定的、持久的存储。 有序的、优雅的部署和伸缩。 有序的、优雅的删除和停止。 有序的、自动的滚动更新。 稳定的主要是针对Pod发生re-schedule后仍然要保持之前的网络标识和持久化存储。这里
前文我们介绍了通过 Longhorn UI 可以对卷进行快照、备份恢复等功能,此外我们还可以通过 Kubernetes 来实现对卷的管理,比如可以在集群上通过 CSI 来实现快照、备份恢复、克隆、扩容等功能支持。
在 Kubernetes 中,PersistentVolume(PV)是一种资源类型,它提供了与存储卷(如硬盘、SAN、NFS)的抽象接口。了解并合理配置 PV 的回收策略对于有效管理存储资源至关重要。
翻译自 Kubernetes Best Practices: A Comprehensive Guide 。
在 Kubernetes 节点发生故障时,在 40 秒内(由 Controller Manager 的 --node-monitor-grace-period 参数指定),节点进入 NotReady 状态,经过 5 分钟(由 --pod-eviction-timeout 参数指定),Master 会开始尝试删除故障节点上的 Pod,然而由于节点已经失控,这些 Pod 会持续处于 Terminating 状态。
PV和PVC是kubernetes存储管理中的重要概念,在日常生产场景中使用非常广泛。本文主要介绍PV和PVC在kubernetes中的基本概念、使用场景以及实现原理。更多PV和PVC的使用细节问题请参考kubernetes官方文档。
容器中的存储都是临时的,因此Pod重启的时候,内部的数据会发生丢失。实际应用中,我们有些应用是无状态,有些应用则需要保持状态数据,确保Pod重启之后能够读取到之前的状态数据,有些应用则作为集群提供服务。这三种服务归纳为无状态服务、有状态服务以及有状态的集群服务,其中后面两个存在数据保存与共享的需求,因此就要采用容器外的存储方案。
蔡靖,腾讯高级后台开发工程师,拥有多年大规模 Kubernetes 集群开发运维经验。目前负责腾讯云TKE存储组件的功能特性实现,以及稳定性与性能的提升。 引言 随着自研上云的深入,越来越多的有状态服务对于在 TKE 集群中使用云上存储能力的需求也越来越强烈。 目前腾讯云容器服务 TKE (Tencent Kubernetes Engine)[1]已支持在 TKE 集群中的应用使用多种存储服务,包括云硬盘 CBS[2]、文件存储 CFS[3]以及对象存储 COS[4]。TKE 通过两种存储插件(In-Tr
首先,StatefulSet 的控制器直接管理的是 Pod。这是因为,StatefulSet 里的不同 Pod 实例,不再像 ReplicaSet 中那样都是完全一样的,而是有了细微区别的。比如,每个 Pod 的 hostname、名字等都是不同的、携带了编号的。而 StatefulSet 区分这些实例的方式,就是通过在 Pod 的名字里加上事先约定好的编号。
我们对 PV 和 PVC 的几种状态应该不算陌生,但是在使用过程中可能也会产生一些疑问,比如为什么 PV 变成 Failed 状态了,新创建的 PVC 如何能够绑定之前的 PV,我可以恢复之前的 PV 吗?这里我们就来对 PV 和 PVC 中的几种状态变化再次进行说明。
每个Node 节点上都运行着以下一组关键进程 - 1. kubelet:负责pod对应的容器创建、启停等任务,同时与master 节点密切协作,实现集群管理的基本功能。 - 2. kube-proxy:实现kubernetes Service 的通信与负载均衡机制的重要组件。 - 3. Docker Engine: Docker 引擎,负责本机的容器创建和管理工作。
Kubernetes 正迅速成为在分布式系统中部署工作负载的事实标准。在这篇文章中,我将通过揭示其底层的设计原则,帮助您更深入地了解 Kubernetes。
通过Rancher Kubernetes Engine运行高可用 PostgreSQL
CSI snapshot是由华为在Kubernetes社区主导开发的存储特性,在K8S 1.12进入Alpha阶段。接下来,我们将分为上下两篇,分别介绍snapshot的创建删除等API以及从snapshot还原数据卷,同时,我们将使用CSI hostpath 插件来演示,如何使用这两种特性。
在没有介绍Kubernetes Volume之前,先来回顾下Docker Volume,Docker Volume常用使用方式有两种,
上一篇文章中,我们讲了deployment的编排技术,也提到了这种编排技术只能编排无状态的pod。但是在我们实际生产环境中,系统复杂很多。比如分布式系统,pod之间往往有依赖关系。再比如mysql数据库,主从节点需要通过binlog同步数据,读写请可能要求发送到不同节点上。对这种有状态的应用,kubernete的解决方案是StatefulSet。
Pod是一组紧密关联的容器集合,支持多个容器在一个Pod中共享网络和文件系统,可以通过进程间通信和文件共享这种简单高效的方式完成服务,是Kubernetes调度的基本单位。Pod的设计理念是 每个Pod都有一个唯一的IP Pod具有如下特征:
数据局部性设置(data locality setting)旨在在以下情况下启用:只要有可能,至少应在与使用该卷的 pod 相同的节点上调度 Longhorn 卷的一个副本。我们将拥有本地副本的特性称为具有 data locality。
Kubernetes 是一个可以移植、可扩展的开源平台,使用声明式的配置并依据配置信息自动地执行容器化应用程序的管理。在所有的容器编排工具中(类似的还有 docker swarm / mesos等),Kubernetes 的生态系统更大、增长更快,有更多的支持、服务和工具可供用户选择。
上篇文章中,我们介绍了 TiDB Operator 的 Controller Manager 的设计和实现,了解了各个 Controller 如何接受和处理变更。在这篇文章中,我们将讨论组件的 Controller 的实现。TiDBCluster Controller 负责了 TiDB 主要组件的生命周期管理,我们将以此为例, 介绍组件控制循环的编排设计。我们将会了解到完成 TiDB 集群的生命周期管理过程中,各种控制循环事件经过了怎样的编排,这些事件中又完成了哪些资源管理操作。在阅读时,大家了解这些工作的大致过程和定义即可,我们将在下一篇文章中具体介绍各个组件如何套用下面的范式。
我们对 PV 和 PVC 的几种状态应该不算陌生,但是在使用过程中可能也会产生一些疑问,比如为什么 PVC 变成 Lost 状态了,新创建的 PVC 如何能够绑定之前的 PV,我可以恢复之前的 PV 吗?这里我们就来对 PV 和 PVC 中的几种状态变化再次进行说明。
ConfigMap 功能在 Kubernetes1.2 版本中引入,许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。ConfigMap API 给我们提供了向容器中注入配置信息的机制,ConfigMap 可以被用来保存单个属性,也可以用来保存整个配置文件或者 JSON 二进制大对象。
使用hostPath会发现当删除一个pod,并且下一个pod使用了指向主机上相同路径的hostPath卷,则新pod将会发现上一个pod留下的数据,但前提是必须将其调度到与第一个pod相同的节点上。
在之前的博文中,我们已经知道了很多 K8S 中的组件了,包括资源控制器等。在资源控制器中,我们说到了 StatefulSet 这个控制器组件,其专门为了有状态服务而生的,而对应的存储要存放到哪里呢?
非官方 k8s helm charts,大规模吞吐需建设微服务集群/中间件集群/边缘存储集群。
在《研发工程师玩转Kubernetes——PVC通过storageClassName进行延迟绑定》一文中,我们利用Node亲和性,让Pod部署在节点ubuntud上。因为Pod使用的PVC可以部署在节点ubuntuc或者ubuntud上,而系统为了让Pod可以部署成功,则让PVC与Pod亲和的ubuntud上的PV绑定。这样Pod在自身节点亲和性和PVC上都满足了条件。
什么是无状态或有状态容器呢?所谓无状态容器应用,意味着容器上应用所使用的历史数据或运行状态不需要进行持久化,重新拉起这个应用时,无需关注这些历史输入。简单来说,例如你要运行一个计算器(而且这个计算器不需要支持历史记录功能),当你重新拉起这个计算器时,之前的数据不需要重新被加载上来,计算器可以认为是一个无状态应用。其它类似的无状态容器应用还包括一些协议转换、请求转发等应用,大体都可以认为是无状态的。
为了保证数据的持久性,必须保证数据在外部存储在docker容器中,为了实现数据的持久性存储,在宿主机和容器内做映射,可以保证在容器的生命周期结束,数据依旧可以实现持久性存储。但是在k8s中,由于pod分布在各个不同的节点之上,并不能实现不同节点之间持久性数据的共享,并且,在节点故障时,可能会导致数据的永久性丢失。为此,k8s就引入了外部存储卷的功能。
Kubernetes 是一个开源的容器编排工具,可以用来管理和部署分布式应用程序。而 ZooKeeper 是一个分布式的开源协调服务,它可以用于协调分布式系统的各种操作,如数据同步、状态监控、配置管理等。在 Kubernetes 中,可以使用 StatefulSet 对 ZooKeeper 进行集群部署和管理,下面我们来详细介绍如何在 Kubernetes 中安装 ZooKeeper 集群。
作为一个后端工程师,因为负责的大部分项目都是Web服务这类的“无状态应用”,在平时工作中接触到的最常用的Kubernetes控制器是Deployment,但是Deployment只适合于编排“无状态应用”,它会假设一个应用的所有 Pod是完全一样的,互相之间也没有顺序依赖,也无所谓运行在哪台宿主机上。正因为每个Pod都一样,在需要的时候可以水平扩/缩,增加和删除Pod。
作者 | Xing Yang, VMware & Xiangqian Yu, Google
Pod是一组紧密关联的容器集合,支持多个容器在一个Pod中共享网络和文件系统,可以通过进程间通信和文件共享这种简单高效的方式完成服务,是Kubernetes调度的基本单位。Pod的设计理念是每个Pod都有一个唯一的IP。
Pod是一组紧密关联的容器集合,支持多个容器在一个Pod中共享网络和文件系统,可以通过进程间通信和文件共享这种简单高效的方式完成服务,是Kubernetes调度的基本单位。Pod的设计理念是 每个Pod都有一个唯一的IP
实际生产环境中,为了稳定和高可用,运维团队一般不会把 MySQL 数据库部署在 Kubernetes 集群中,一般是用云厂商的数据库或者自己在高性能机器(如裸金属服务器)上搭建。
PersistentVolume (PV) 是由管理员设置的存储,它是群集的一部分。就像节点是集群中的资源一样,PV 也是集群中的资源。 PV 是Volume 之类的卷插件,但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节,即 NFS、iSCSI 或特定于云供应商的存储系统。
Kubernetes 作为资源调度和应用编排的开源系统,正在成为云计算和现代 IT 基础架构的通用平台。JuiceFS CSI Driver 实现了容器编排系统的存储接口,使得用户可以在 Kubernetes 中以原生的方式使用 JuiceFS。
K8S的存储系统从基础到高级又大致分为三个层次:普通Volume,Persistent Volume 和动态存储供应。
动态模式: 管理员无需手动创建PV,而是通过StorageClass的设置对后端存储进行描述,标记为某种"类型(Class)",此时要求PVC对存储的类型进行声明,系统将自动完成PV的创建及PVC的绑定,PVC可以声明为Class为"",说明该PVC禁止使用动态模式
Deployment并不能满足所有的应用场景,因为它默认对应用做了一个简化假设处理,认为一个应用的所有Pod是完全一样的,但往往在实际应用中,多个实例相互间是存在依赖关系的,比如:主从关系,主备关系,实例与数据之间的关系等。
AiSuite 是 NAVER 开发者所使用的人工智能平台,它支持 NAVER 的各种服务的开发和运维。
服务端的安装分为独立单机模式和分布式安装, 以下单机模式的安装方法. 分布式的安装和单机模式的安装类似,只是根据传参不同
Kubernetes为了能更好的支持有状态应用的数据存储问题,除了基本的HostPath和EmptyDir提供的数据持久化方案之外,还提供了PV,PVC和StorageClass资源对象来对存储进行管理。
领取专属 10元无门槛券
手把手带您无忧上云