暂时未有相关云产品技术能力~
暂无个人介绍
今天,我们聊一下Kubernetes Container相关话题,什么是Container?
上篇文章,我们讲到容器引擎Docker与Podman,关于K8S弃用Docker的根本原因在于容器运行时接口CRI,Kubelet 之前使用的是一个命名为 dockershim 的模块,用以实现对 Docker 的 CRI 支持。具体,可参考上篇文章:容器引擎Docker与Podman解析。本文主要针对CRI进行简要解析,以使得大家能够更深入了解K8S底层运行机制,以便能够更好地掌握容器生态技能。
最近技术群里有朋友问我,不是说K8S要弃用Docker了吗?还要不要继续学习这块内容?是不是得改行卖白菜了?
古语有云:“知彼知己,百战不殆。不知彼而知己,一胜一负。不知彼,不知己,每战必殆。” 这句话同样也适用于技术体系。无论我们在落地,还是在学习、实践某一项技术,对提供相同功能的体系框架的对比学习,可以使得我们能够快速、全面地去拥抱其生态。
一提到“Kill”命令,大家是不是很兴奋,潜意识觉得自己大展宏图之刻即将到来,仿佛自己就是那个黑暗的夜空下拿着长剑的武士,站在高高的山崖顶层,xx一切。。。别,醒醒吧,孩子(大侠)!大家在停止Java进程时(当然,不仅仅是Java,其他应用也同样适用,本文主要针对Java程序进行解析),有没有想过为什么要用kill -9呢?这样操作对吗?
Rancher是What?一个开源的企业级容器管理平台。通过Rancher,企业再也不必自己使用一系列的开源软件去从头搭建容器服务平台。Rancher提供了在生产环境中使用的管理Docker和Kubernetes的全栈化容器部署与管理平台。
随着时代的发展,应用服务的架构也随之进行不停的变迁,从单一的架构到面向服务的SOA、以及正在流行的微服务架构,甚至正在火热的服务网格,无论何种架构,适合于技术的需要以及业务的发展才是最重要的。因此,无论是以Spring Cloud和Dubbo第一代的微服务框还是以Service Mesh下一代的微服务框架,对于服务的治理仍然是微服务架构中最核心、最重要的一部分,服务治理最基础的组件是注册中心。
随着Kubernetes生态的不断壮大,一度被誉为新一代数据中心操作系统(DCOS),从资源角度来讲,K8S其核心工作也是管理整个集群的计算资源,并按需合理分配给系统里的程序(以Pod为基础的各种WorkLoad)。本质也是解决资源与业务负载之间供需平衡的问题。因此,了解Kubernetes自动扩展功能的相关原理,可以帮助我们在资源管理层面获得更多的价值,有利于提升运维效能。
之前文章我们讲解了Spring Boot提供的 Actuator 模块以实现应用的监控与管理。具体可参考:Spring Boot Actuator解析。Spring Boot Actuator基于http、jmx、ssh、telnet等组件实现应用程序的管理和监控。同时,提供了应用的审计(Auditing)、健康(health)状态信息、数据采集(metrics gathering)统计等监控运维的功能。除此之外,我们可以自定义扩展 Actuator 端点(Endpoint) 监控指标。
Docker-Compose项目是Docker官方的一个开源项目,其主要职责是负责实现对Docker容器集群的快速编排。
通常,我们在了解应用服务的性能时,都会去在所定义的垃圾收集日志文件中去分析GC活动轨迹,在gc.log文件中,我们经常会看到每个GC事件所打印的三种时间类型: “ User ”、“ Sys ”及“ Real ”,它们分别表示什么呢?具有哪些象征性意义呢?本文将结合作者的相关实际经验进行简要解析,希望阅读完本篇文章后对大家在GC Log这块的问题定位与分析有所帮助。
对于Java语言来说是不用刻意手动去释放内存,同时,也尽可能不需要手动去干预Java虚拟机的GC行为。在本篇文章中,我们试图从多个方面去解析有关System.gc()API调用的最常见问题。希望对需要了解这块技术的朋友有所帮助。
我们都知道,在K8S集群中,每个Pod都有自己的私有IP地址,并且这些IP地址不是固定的。这意味着其不依赖IP地址而存在。例如,当我们因某种业务需求,需要对容器进行更新操作,则容器很有可能在随后的启动运行过程中被分配到其他IP地址。此外,在K8S集群外部看不到该Pod。因此,Pod若单独运行于K8S体系中,在实际的业务场景中是不现实的,故我们需要通过其他的策略去解决,那么解决方案是什么? 由此,我们引入了Serivce这个概念以解决上述问题。
上篇文章我们简要解析了用户CPU时间相关概念及应用实践,具体可参考链接🔗: Linux系统之User CPU time解析。 回顾之前的内容:在Linux操作系统中,通常采用8个不同的指标来研究Linux / Unix操作系统中的CPU消耗:用户CPU时间(us)、系统CPU时间(sy)、良好的CPU时间(ni)、空闲CPU时间(id)、等待CPU时间(wa)、硬件中断CPU时间(hi),软件中断CPU时间(si),被盗CPU时间(st)。在本文中,我们主要针对“等待CPU时间”进行解析。
随着Go的逐渐流行,基于性能、高效及稳定部署,越来越多的企业开始将其应用框架移植至Go平台。本文主要基于Goland开发平台和Docker容器环境运行,简要介绍Go语言开发的Web项目的容器化部署相关操作。
G1 GC是一种自适应垃圾收集算法,自Java 9以来已成为默认的GC算法。今天主要通过分享一些简单的技巧来调整G1垃圾收集器以获得最佳运行性能。
在Linux操作系统中,通常采用8个不同的指标来研究Unix / Linux操作系统中的CPU消耗:用户CPU时间(us)、系统CPU时间(sy)、良好的CPU时间(ni)、空闲CPU时间(id)、等待CPU时间(wa)、硬件中断CPU时间(hi),软件中断CPU时间(si),被盗CPU时间(st)。在本文中,我们主要对“用户CPU时间”进行解析。
Java虚拟机(JVM)生成3个关键工件,这些工件对于优化性能和解决生产问题很有用。这些工件是: 垃圾收集(GC)日志 线程转储(ThreadDump) 堆转储(HeapDump 在本文中,我将尝试简要解析下这3个关键工件,描述下在什么场景中使用它们,它们的外观如何,如何捕获它们,如何分析它们及其之间的差异。
Portainer是一款免费、开源的Docker的图形化管理工具,其能够提供状态显示面板、应用模板快速部署、容器镜像网络数据卷的基本操作(包括上传下载镜像,创建容器等操作)、事件日志显示、容器控制台操作、Swarm集群和服务等集中管理和操作、登录用户管理和控制等功能。功能十分全面,基本能满足中小型单位对容器管理的全部需求。
Docker镜像用作Docker执行程序中的主映像。它们是容器的蓝图,提供了有关如何生成容器的说明。在本文中,我将介绍一些经常被忽视的概念,这些概念将有助于优化Docker镜像开发和构建过程。
又是fastjson!又是这家伙!至少经历了2次+这样的场景。我不知道这家伙又得罪了哪位大仙,频繁被“黑”。fastjson到底做错了什么?为什么会被频繁爆出漏洞?但是作为一个技术人(兴趣爱好者),我更关注的是它为什么会频繁被爆漏洞?而其他的Gson却没有。通过对fastjson的releaseNote以及部分源代码进行查阅,发现此现象跟fastjson中的一个AutoType特性有关联。
在基于物理的服务器(此处主要与容器平台进行区分,故此描述)上运行Java应用程序时,我们通常会使用Java虚拟机参数"-Xms、-Xmx"来指定Java堆内存的初始值和最大值。如果要将我们的应用程序移植到容器平台,如何在容器环境中配置Java堆内存大小呢?有没有最佳做法?在本文中,我们将讨论可用于指定Java堆内存大小的JVM参数以及最优选择。
本文主要介绍基于SCRAM进行身份验证,使用Kafka ACL进行授权,SSL进行加密以及使用camel-Kafka连接Kafka群集以使用camel路由生产和消费消息的过程。
一款新的GC日志分析仪器,业界首个基于人工智能机器学习指导的垃圾收集日志分析工具。 GCeasy具有内置的智能功能,可以自动检测JVM和Android GC日志中的问题并为之推荐解决方案。
当有我们的服务器CPU资源使用率(usr%)较高时,或者是一个基于 JAVA 的 Web 应用运行的比预期慢的时候,我们需要使用 Thread Dumps进行分析。线程转储是诊断CPU尖峰,死锁,响应时间差,内存问题,应用程序无响应以及其他系统问题的一项重要工作或者环节。
堆转储是诊断在Java虚拟机中与内存相关的问题的重要文件,例如内存泄漏、应用请求缓慢,垃圾回收问题以及各种各样的java.lang.OutOfMemoryError异常。堆转储文件也是优化、分析内存消耗的重要工具。
根据CNCF的最新年度调查,很明显,很多人对在他们的项目中使用服务网格表现出了浓厚的兴趣,并且许多人已经在他们的生产中使用它们。近69%的人正在评估Istio,64%的人正在研究Linkerd。Linkerd是市场上第一个服务网格,但是Istio使服务网格更受欢迎。这两个项目都是最前沿的,而且竞争非常激烈,因此选择一个项目是一个艰难的选择。在此博客文章中,我们将了解有关Istio和Linkerd体系结构,其运动部件的更多信息,并比较其产品以帮助您做出明智的决定。
Actuator 是 SpringBoot 项目中一个非常强大一个功能,有助于对应用程序进行监视和管理,通过 Restful Api 请求来监管、审计、收集应用的运行情况。
云原生(Cloud Native)可以认为是一套技术体系或生态,它包含2大部分:云(Cloud)和原生(Native)。云(Cloud)表示应用程序位于云中,而不是传统的数据中心;原生(Native)表示应用程序从设计之初即考虑到云的环境,原生为云而设计,在云上以最佳状态运行,充分利用和发挥云平台的弹性和分布式优势。
很多小伙伴在遇到某一接口服务性能问题时,比如说,TPS上不去、响应时间拉长、应用系统出现卡顿,某一请求出现超时等等现象,往往显得苍白无力,无从下手。 针对系统负载性能,很大一部分人潜意识会认为CPU使用率等同系统负载,或者直接反应系统负载情况,这种理解对吗?本文将从2个纬度合理进行分析系统负载以及CPU与Load Average之间的关联。
上篇文章介绍了Ingress-nginx的基本架构原理,具体可参考: 编排系统K8S Ingress-nginx介绍 本篇重点以源码为基础,深入讲解 Ingress-nginx的内部工作流以及整体工作模式。
在Kubernetes编排系统中,容器服务和Pod的IP地址仅允许在集群网络内部使用,对于集群外的应用是不可见的。为了使外部的应用能够访问集群内的服务,在Kubernetes平台中目前提供了以下3种通用型方案:
CouchBase是一款开源的、分布式的nosql数据库,主要用于分布式缓存和数据存储领域。能够通过manage cache提供快速的亚毫米级别的k-v存储操作,并且提供快速的查询和其功能强大的能够指定SQL-like查询的查询引擎。
Greys为一款“事后工具” ,即服务已经上线了,无法再通过打印日志等方式进行埋点分析,此时可以借助此工具,来跟踪代码执行耗时、堆栈运行情况等。使用Greys,我们无需编写 脚步,它是命令交互式的,直接输入命令指定监控的类、方法。
Curl是一个非常实用的,用来与服务器之间传输数据的工具,支持的协议包括 (DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET and TFTP),Curl设计为无用户交互下完成工作。
CMS,全称“ Concurrent-Mark-Sweep”,是一款并发的、使用标记-清除算法的垃圾回收器,如果老年代采用CMS垃圾回收器,则需要在应用服务Java虚拟机启动参数中配置关键字:-"XX:+UseConcMarkSweepGC"。
通常项目上容器后,通过docker的方式来启动系统,需要经过一系列相关操作,例如:编译、打jar包、打镜像、发布、部署及启动等阶段。在各种自动化工具的出现,对打包、部署等工作带来了便利,一般交给git+Jenkins或者gitlab方式进行自动化部署。 然而,在项目开发、调试阶段,需要借助开发平台进行相关操作。本文主要讲述:如何在IDEA中通过插件来部署docker项目,以方便开发阶段的调试部署工作。
今天我们来了解下K8S上的Service资源的相关话题,这是容器化体系的第1篇,基本的概念、基础理论不在本章描述。
通常,在基于Java生态体系中的应用程序抛出异常时,生产环境都会通过gc log[当然,也有2愣子直接去线上环境进行各种骚操作]去捕获各种可疑线索,以便快速、高效定位及解决问题。
针对以Java主导的企业级应用开发,Java虚拟机是整个项目架构的灵魂所在。只有弄清楚其内存分配及垃圾回收机制才能够在项目建设活动过程中游刃而余,无论是基于当前流行的微服务体系(以Spring家族的 Spring Cloud或以Ali家族的Dubbo)or 即将(已经)流行的服务网格体系。
Kafdrop是Apache Kafka的开源Web UI可视化工具。
Kafka Magic是一款Apache Kafka的Web UI可视化工具。
针对GC中发生的"Allocation Failure"
无论是基于1.x or 2.x,作为Spring框架的核心模块,Spring Boot用于轻松构建独立的生产级基于Spring的应用程序。它是建立在核心Spring Framework之上开发。 Spring Boot遵循一个分层的体系结构,其中每个层都与其直接在其下方或上方的层(层次结构)进行通信。在了解Spring Boot体系结构之前,我们必须了解其中的不同层和类。