Pod 的重启策略有 3 种,默认值为 Always. Always : 容器失效时,kubelet 自动重启该容器: OnFailure : 容器终止运行且退出码不为0时重启: Never : 不论状态为何, kubelet 都不重启该容器. 失败的容器由 kubelet 以五分钟为上限的指数退避延迟(10秒,20秒,40秒…)重新启动,并在成功执行十分钟后重置. 在yaml编排文件中restartPolicy: OnFailure要和container并排. [root@k8s-master

上一章我们已经通过yaml文件将.netcore程序跑起来了,但还有一下细节问题可以分享给大家. 1.pod管理 1.1创建pod kubectl create -f netcore-pod.yaml 我们创建一个netcore-pod.yaml文件,内容如下: apiVersion: v1 kind: Pod #指明类型 metadata: name: netcore-pod labels: app: netcorepod spec: containers: - name: netcorepo

关键词:k8s.jvm.高可用 1.背景 最近有运维反馈某个微服务频繁重启,客户映像特别不好,需要我们尽快看一下. 听他说完我立马到监控平台去看这个服务的运行情况,确实重启了很多次.对于技术人员来说,这既是压力也是动力,大多数时候我们都是沉浸在单调的业务开发中,对自我的提升有限,久而久之可能会陷入一种舒适区,遇到这种救火案例一时间会有点无所适从,但是没关系,毕竟...... "我只是收了火,但没有熄炉",借用电影中的一句话表达一下此时的心情. 2.初看日志 我当即就看这个服务的运行日志

Docker+K8s基础篇(三) kubernetes上的资源 A:k8s上的常用资源 Pod的配置清单 A:Pod上的清单定义 B:Pod创建资源的方法 C:spec下其它字段的介绍 Pod的生命周期 A:Pod的生命周期阶段 B:容器的两种探测(探针) C:容器启动后和终止前钩子 ♣一:kubernetes的资源 A:k8s上的常用资源: 1:workload(工作负载型对象): pod,Replicaset,Deployment,statefulSet,DaemonSet,Job,Cron

一.K8S介绍: Kubernetes(k8s)是Google开源的容器集群管理系统.在Docker技术的基础上,为容器化的应用提供部署运行.资源调度.服务发现和动态伸缩等一系列完整功能,提高了大规模 容器集群管理的便捷性. 1.K8S优势: 容器编排:轻量级:开源:弹性伸缩:负载均衡 2.重要概念: Cluster: 是 计算.存储和网络资源的集合,k8s利用这些资源运行各种基于容器的应用. Master: master是cluster的大脑,他的主要职责是调度,即决定将应用放在那里运行.ma

#k8s常用资源 工作负载:Pod,rs(ReplicasSet),deploy(Deployment),sts(StatefulSet),ds(DaemonSet),Job,Cronjob 服务发现及负载均衡:svc(Service), ing(Ingress) 配置与存储:Volume,pv( persistentvolumes ),pvc,cm(ConfigMap),Secret,DownwardAPI 集群级: ns(Namespace),Node,Role,ClusterRole,Ro

最近在公司的数据同步项目(以下简称 ZDTP)中,需要使用到分布式调度数据同步执行单元,目前使用的方案是将数据同步执行单元打包成镜像,使用 K8s 进行调度. 在 ZDTP 中,数据同步的动作可抽象成一个执行单元(以下称为 worker),类似于线程执行单元 Runnable ,Runnable 放入一个队列中等待线程的调度执行,执行完 Runnable 即完成了它的使命.当用户在 ZDTP 控制台中创建同步任务并启动任务时,会根据同步任务的配置,产生若干个用于该任务的 worker,假设这些

说明:部署的过程中请保证每个命令都有在相应的节点执行,并且执行成功,此文档已经帮助几十人(仅包含和我取得联系的)快速部署k8s高可用集群,文档不足之处也已更改,在部署过程中遇到问题请先检查是否遗忘某个步骤,文档中每个步骤都是必须的. 经测验此文档也适合高可用部署k8s v.12,只需修改对应版本号就可. 1.部署架构 详细架构: 2.基本配置 主机名 IP地址 说明 组件 k8s-master01 ~ 03 192.168.20.20 ~ 22 master节点 * 3 keepalived.n

什么是Pod 一个Pod(就像一群鲸鱼,或者一个豌豆夹)相当于一个共享context的配置组,在同一个context下,应用可能还会有独立的cgroup隔离机制,一个Pod是一个容器环境下的“逻辑主机”,它可能包含一个或者多个紧密相连的应用,这些应用可能是在同一个物理主机或虚拟机上. Pod 的context可以理解成多个linux命名空间的联合 PID 命名空间(同一个Pod中应用可以看到其它进程) 网络 命名空间(同一个Pod的中的应用对相同的IP地址和端口有权限) IPC 命名空间(同一个

4.6.存储 4.6.1.ConfigMap 创建方式 文件夹/文件创建 mkdir dir cd dir cat > c1.properties <<EOF c1.name=c1 EOF cat > c2.properties <<EOF c2.name=c2 EOF cd .. cat > c3.properties <<EOF c3.name=c3 EOF # configmap 简写为 cm # 根据目录创建 kubectl create co

现状 加参数 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=logs/test.dump 可以实现在jvm发生内存错误后 会生成dump文件 方便开发人员分析异常原因. 当运行在k8s中,如果进程发生错误 导出dump文件后 ,k8s会重启dokcer容器,上一次崩溃生成的dump文件就没有了.如果应用并没有完全崩溃 此时极其不稳定 最好也能通知到技术人员来处理.这样不方便我们排查原因 所有写了一个小工具.大概原理如下 1. -XX:+Heap

使用 PM2 启动应用程序 时,应用程序会在自动退出.事件循环为空 (node.js) 或应用程序崩溃时自动重新启动. 但您也可以配置额外的重启策略,例如: 使用定时任务重新启动应用程序 文件更改后重新启动应用程序 当应用程序达到内存阈值时重新启动 延迟启动和自动重启 默认情况下,在崩溃或退出时禁用自动重启(应用程序始终使用 PM2 重启) 在特定的指数增长时间自动重启应用程序 使用定时任务重新启动应用程序 使用以下命令设置定时重启的任务 $ pm2 start server.js --cron

作为 Kubernetes 项目里最核心的编排对象,Pod 携带的信息非常丰富.其中,资源定义(比如 CPU.内存等),以及调度相关的字段.在本篇,我们就先从一种特殊的 Volume 开始,来帮助你更加深入地理解 Pod 对象各个重要字段的含义. 这种特殊的 Volume,叫作 Projected Volume,你可以把它翻译为“投射数据卷”. (备注:Projected Volume 是 Kubernetes v1.11 之后的新特性) 这是什么意思呢? 在 Kubernetes 中,有几种特

Pod API属性详解 Pod是k8s集群中的最小编排单位.将这个设计落实到API对象上,容器就成了Pod属性里一个普通的字段.那么到底哪些属性属于Pod对象,哪些属性属于容器的呢?先看下面的一段描述: 假如把Pod看成传统环境里的"机器".那么容器就是运行在这个"机器"里的"用户程序",这样很多关于Pod对象的设计就非常容易理解了.凡是调度.网络.存储,以及安全相关的属性,基本上是Pod级别的.他们的共同特征是:描述的是"机器&quo

前言 本文Harbor高可用依照Harbor官网部署,主要思路如下,大家可以根据具体情况选择搭建. 部署Postgresql高可用集群.(本文选用Stolon进行管理,请查看文章<kubernetes下Stolon部署高可用Postgresql>) 部署redis高可用集群.(本文选用Helm对redis进行高可用部署,请查看文章<kubernetes部署高可用redis>,该文以整理好redis编排文件可直接使用) 部署Harbor高可用集群.(本文主要阐述Harbor的高可用部

Pod控制器应用进阶:imagepullpolicy: 镜像获取策略 Always,Never,IfNoPresent 暴露端口: portslabels 标签可以后期添加修改. ============================================资源标签: key=value 注意键值 key 只能是字母数字下划线 _ - .等,且只能是字母或者数字开头及结尾,中间可以有下划线等,长度不能超过64个字符 value 可以为空,只能是字母数字下划线 _ - .等,且只能是字母

目录 Pod 资源 标签 给资源打标签 标签选择器 Pod 生命周期 pod状态探测 livenessProbe 状态探测 livenessProbe exec 测试 livenessProbe httpGet 测试 readinessProbe 就绪性探针 Pod 控制器 ReplicaSet 控制器 Deployment 控制器 测试滚动更新 DaemonSet 控制器 Pod 资源 spec.containers <[]object> - name <string> imag

pod对象自从创建开始至终止退出的时间范围称为生命周期,在这段时间中,pod会处于多种不同的状态,并执行一些操作:其中,创建主容器为必须的操作,其他可选的操作还包括运行初始化容器(init container).容器启动后钩子(start hook).容器的存活性探测(liveness probe).就绪性探测(readiness probe)以及容器终止前狗子(pre stop hook)等,这些操作是否执行则取决于pod的定义 一.pod的相位 无论是手动创建还是通过控制器创建pod,pod

一 POD的容器资源限制 1.1 限制内容 有两个参数 QoS Class: BestEffort,表示尽可能的满足使用,级别较低,但当资源不够时,会杀掉这个容器 resources: {}这里指定为空,则使用上面的参数 一般定义 resources: requests: #表示最小需求 cpu: "0.1" memory: "32Mi" limits: #最大限制 cpu: " memory: "128Mi 1.2 配置资源限制 [root@d

一.资源清单 1,定义: 在k8s中一般使用yaml格式的文件来创建符合我们预期的资源,这样的yaml被称为资源清单. 使用资源清单创建Pod: kubectl apply -f nginx.yaml 定义nginx.yaml内容为: apiVersion: v1 kind: Pod metadata: name: my-pod #自定义的名称只能用小写字母使用 - 连接,驼峰 或者 _ 连接会报错 labels: app: nginx-app version: v1 spec: contain

Kubernetes服务pod的健康检测liveness和readiness详解 接下来给大家讲解下在K8S上,我们如果对我们的业务服务进行健康检测. Health Check.restartPolicy 这里我们再进一步,来聊聊K8s上面服务的健康检测特性.在K8s上,强大的自愈能力是这个容器编排引擎的非常重要的一个特性,自愈的默认实现方式是通过自动重启发生故障的容器,使之恢复正常.除此之外,我们还可以利用Liveness 和 Readiness检测机制来设置更为精细的健康检测指标,从而实现如