岳家瑞,腾讯云后台开发工程师,日常负责K8s生态和运行时相关工作,包括K8s插件开发和运行时问题排查。
istio 支持多平台,不过 Istio 和 k8s 的兼容性是最优的,不管是设计理念,核心团队还是社区, 都有一脉相承的意思。但 istio 和 k8s 的适配并非完全没有冲突, 一个典型问题就是 istio 需要 k8s service 按照协议进行端口命名(port naming)。
当我们删除集群中的某个namespace之后,有时候namespace并没有按照我们的期望正常删除,而是一直卡在Terminating状态。本文主要讨论下Terminating状态发生的可能性以及解决办法。
我们在《Kubernetes工作负载管理》中主要介绍了无状态应用的管理,当时也有提到有状态应用,但是由于那时候还没有解释数据如何持久化就没有做深度的介绍,而在这章,我们会着重介绍如何进行有状态应用的管理。
背景: 我们都知道在k8s中namespace有两种常见的状态,即Active和Terminating状态,其中后者一般会比较少见,只有当对应的命名空间下还存在运行的资源,但是该命名空间被删除时才会出现所谓的terminating状态,这种情况下只要等待k8s本身将命名空间下的资源回收后,该命名空间将会被系统自动删除。但是今天遇到命名空间下已没相关资源,但依然无法删除terminating状态的命名空间的情况,特此记录一下.
Kubernetes StatefulSets[1]自从在 1.5 中引入,并在 1.9 中变得稳定以来,已经被广泛用于运行有状态应用程序。它提供稳定的单元身份、持久的单元存储,以及有序的部署、扩展和滚动更新。你可以将 StatefulSet 视为运行复杂的有状态应用程序的原子构建块。随着 Kubernetes 的使用越来越多,需要 StatefulSets 的场景也越来越多。在你对 StatefulSets 使用 OrderedReady pod 管理策略的情况下,许多这样的场景需要比当前支持的一次一个 Pod 更新更快的滚动更新。
当涉及到分布式系统,处理故障是关键。Kubernetes通过利用可以监视系统状态并重新启动已停止执行的服务的控制器(controllers)来解决这个问题。另一方面,Kubernetes通常可以强制终止您的应用程序,作为系统正常运行的一部分。
健康检测接口用于检测应用的健康状态,在K8S中,使用Readiness和Liveness分别来探测应用是否就绪和是否存活,如果未就绪或者未存活,K8S会采取相应的措施来确保应用可用。
Docker 是基于容器技术实现的,容器技术最开始是基于 Linux Container(简称 LXC)技术实现的,通过内核提供的 Namespace 和 Cgroup 机制,实现了对应用程序的隔离以及物理资源的分配。
StatefulSet副本启动顺序按照名称0,1,2,只有web-0完全启动之后才会启动web-1,web-1完全启动之后才会启动web-2
kai 开 gong 工 da 大 ji 吉 新年新气象,更要1G棒 2020年没写完的代码,现在还有思路吗? 2021年开始使用云原生技术了吗? 一开工就遇到各种头痛的问题,“开工大吉”要演变为”开工大战“? 别急别急,小编已为你整理好 50+篇云原生技术干货包及3w多字的《云原生路线图手册》和云原生最佳实践案例 。 开工大吉,干了这碗“陈酿”精华的技术干货,2021快人一步! K8s 性能优化实践系列 万级 K8s 集群背后 etcd 稳定性及性能优化实践 如何根据不同业务场景调节 HPA 扩缩容灵敏
问题出在这里:DiscoveryFailed:Discovery failed for some groups, 1 failing: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request
云原生技术干货文章合集,来咯~ 2020 年,要说咱们技术圈子里什么最火? 云原生肯定是那 NO.1 截止目前,我们不难看出,K8s 容器、服务网格、大数据容器化、DevOps 等云原生技术,已经妥妥地发展成为众多企业和开发者人群持续践行且密切关注的技术领域,甚至将会是各个企业提升核心竞争力的技术布局。 俗话说,众人拾柴火焰高,人多力量大 。 在过去的一年时间里,腾讯云原生联手腾讯云容器中心研发团队及社区优秀的云原生技术爱好者,围绕云原生相关技术,结合真实业务场景与用户痛点,从技术基础
「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/container )。
删除monitoring命名空间时总也无法彻底删除,发现monitoring处于Terminating状态,故有此文。
K8S是一个开源的,用于管理云平台中多个主机上的容器化应用,Kubernetes的目标是让部署容器化变得简单并且高效
上一篇《部署过程解析与安装Dashboard》中我们了解K8S的部署过程,这一篇我们来了解一下K8S为我们提供的几种应用运行方式:Deployment、DaemonSet与Job,它们是Kubernetes最重要的核心功能提供者。考虑到篇幅和更新速度,我将其分为两篇文章,本篇会主要介绍Deployment,主要参考自CloudMan《每天5分钟玩转Kubernetes》,也推荐大家购买阅读。
上一篇文章中,我们讲了deployment的编排技术,也提到了这种编排技术只能编排无状态的pod。但是在我们实际生产环境中,系统复杂很多。比如分布式系统,pod之间往往有依赖关系。再比如mysql数据库,主从节点需要通过binlog同步数据,读写请可能要求发送到不同节点上。对这种有状态的应用,kubernete的解决方案是StatefulSet。
我们对 PV 和 PVC 的几种状态应该不算陌生,但是在使用过程中可能也会产生一些疑问,比如为什么 PVC 变成 Lost 状态了,新创建的 PVC 如何能够绑定之前的 PV,我可以恢复之前的 PV 吗?这里我们就来对 PV 和 PVC 中的几种状态变化再次进行说明。
每次当我们发布新版本的时候总是慌兮兮,一方面是担心有 bug,另一方面其实重启应用会带来一些抖动,可能有几秒钟或者几个请求的不正常,从而担心用户在这段时间内的操作。那么如何在应用重启的过程中尽可能的保证不会带来抖动,从而平滑又优雅的重启呢?
大家好,本篇是个人的第 2 篇文章。是关于在之前项目中,k8s 线上集群中 Node 节点状态变成 NotReady 状态,导致整个 Node 节点中容器停止服务后的问题排查。
在上一篇中,讲解了容器持久化存储,从中我们知道什么是PV和PVC,这一篇我们讲通过StatefulSet来使用它们。
在 Kubernetes 节点发生故障时,在 40 秒内(由 Controller Manager 的 --node-monitor-grace-period 参数指定),节点进入 NotReady 状态,经过 5 分钟(由 --pod-eviction-timeout 参数指定),Master 会开始尝试删除故障节点上的 Pod,然而由于节点已经失控,这些 Pod 会持续处于 Terminating 状态。
使用 K8s 的原生命令 kubectl部署一个web应用的镜像到 k8s 集群中,并通过 Ingress 将部署的服务暴露出来由外部访问。
命名空间,即 namespace,是对一组资源和对象的抽象集合,比如可以将系统内部的对象划分为不同的项目组或用户组。
今天我们讨论的这个问题,跟 K8s 集群的 Namespace 有关。Namespace 是 K8s 集群资源的“收纳”机制。我们可以把相关的资源“收纳”到同一个 Namespace 里,以避免不相关资源之间不必要的影响。
StatefulSet 旨在与有状态的应用及分布式系统一起使用。本节将通过使用 StatefulSet 部署一个简单的 Web 应用,来演示StatefulSet的常规操作,包括:
现象:某个Node频繁出现“PLEG is not healthy: pleg was last seen active 3m46.752815514s ago; threshold is 3m0s”错误,频率在5-10分钟就会出现一次。
答:Kubenetes是一个针对容器应用,进行自动部署,弹性伸缩和管理的开源系统。主要功能是生产环境中的容器编排。 K8S是Google公司推出的,它来源于由Google公司内部使用了15年的Borg系统,集结了Borg的精华。 2、 K8s架构的组成是什么?
从前面的文章我们知道,Kubernetes 脱胎于 Google 的 Borg,Borg 在 Kubernetes 诞生之初已经在 Google 内部身经百战 10 余年,且不说它的历史源远流长,就凭它是出自 Google 那帮天才工程师之手,就知道它的学习难度不低。
还有2天,就要迎来中秋小长假啦 这个中秋节你打算怎么过? 小云选择把这篇干货全部拿下! 云原生技术干货文章合集,来咯~ 2021 年,要说咱们技术圈子里什么最火? 云原生肯定是那 NO.1 不管你是刚入门的新手小白,还是涉足云原生已久的“大神”。 只需收藏这一篇,15个系列100+篇超实用云原生技术干货,只需手指一点,轻松学技术! 以下是整理的15个系列合集 (1)Kubernetes 降本增效系列文 (2)K8s 性能优化实践系列文 (3)最佳实践案例 (4)运维排障系列 (5)容器镜像
除了deployment是v1的升级版,其他的基本都是v1。 # kubectl api-versions
我们对 PV 和 PVC 的几种状态应该不算陌生,但是在使用过程中可能也会产生一些疑问,比如为什么 PV 变成 Failed 状态了,新创建的 PVC 如何能够绑定之前的 PV,我可以恢复之前的 PV 吗?这里我们就来对 PV 和 PVC 中的几种状态变化再次进行说明。
整个k8s是推荐我们使用资源文件清单的格式编写, 资源清单有5个顶级的字段组成:apiVersion、kind、metadata、spec、status ,status是k8s集群运行的时候需要去关注的,即机器需要去关注的,而前面这四个,不管是开发工程师还是运维工程师都需要做一些基本的了解,以及探讨pod的生命周期。
优雅停止(Graceful shutdown) 这个说法来自于操作系统,我们执行关机之后都得 OS 先完成一些清理操作,而与之相对的就是硬中止(Hard shutdown),比如拔电源。
问题描述:查看pod日志报错,Normal Killing 39s (x735 over 15h) kubelet, 10.179.80.31 Killing container with id docker://apigateway:Need to kill Pod,可能是磁盘满了,无法创建和删除 pod
HorizontalPodAutoscaler, k8s的版本是1.14.
毫无疑问,Kubernetes 是个伟大的开源作品,给作者所在团队中极大地提高了生产力,但在使用过程中,相信很多人跟作者一样,会遇到各种各样的问题,有时候解决的过程也是非常享受,某些问题还可能反复遇到。本篇文章记录了本人在使用开始接触 Kubernetes 至今遇到的各类问题及解决方案, 希望对其它同学有所帮助。
官方源码链接:https://github.com/chaostoolkit/chaostoolkit
[toc] 0x00 Controller 介绍 Q: 什么是资源控制器(资源控制器介绍)? 答:Kubernetes中内建了很多controller(控制器),这些相当于一个状态机,用来控制Pod的
最近部署kubesphere时,使用kubectl delete -f xxx.yaml,再次执行 kubectl apply -f xxx.yaml,提示:
在讲述一系列相关专业术语之前,先尝试用一个通俗易懂的故事来说明 Kubernetes 中 node 与 pod 之间的爱恨情仇。
控制器又称工作负载是用于实现管理 pod 的中间层,确保 pod 资源符合预期的状态,pod 的资源出现故障时,会尝试 进行重启,当根据重启策略无效,则会重新新建 pod 的资源。
上一篇 文章我们围绕如何合理利用资源的主题做了一些最佳实践的分享,这一次我们就如何提高服务可用性的主题来展开探讨。
本文主要围绕k8s command展开讨论。(deployment.spec.template.spec.containers[n].command) 主要聊聊平台在接入用户业务时,如何保证满足业务基本需求情况下增强平台易用性。
没脑子,所以就在一个2c2g的虚拟机上创建100个pod玩玩,然后就整个挂了,各种oom的日志像疯了一样。
导读:随着 Kubernetes 集群规模和复杂性的增加,集群越来越难以保证高效率、低延迟的交付 pod。本文将分享蚂蚁金服在设计 SLO 架构和实现高 SLO 的方法和经验。
发现计算节点重启后,所有的该节点上的vm被删除了,查看vm对应的qemu日志,qemu-kvm: terminating on signal 15 from pid 1 (/usr/lib/systemd/systemd) 与此同时,openvswitch服务出错,控制节点上执行neutron agent-list,计算节点的openvswitch-agent服务状态显示也不是笑脸了,是xxx
领取专属 10元无门槛券
手把手带您无忧上云