前言

上一年的这个时候, 笔者捣鼓完那个用minikube做的demo用minikube模拟基于Kubernetes平台的容器化改造之后, 就一直惦记着要不要弄一个自己用的kubernetes高可用集群, 再写个专题.

现在来填坑了!

前言

在2022年的当下, 微服务以及容器技术仍然是互联网行业的主流方向. 在真实的生产环境中, 要如何优雅地实现从代码到容器镜像这一步骤, 也俨然成了众多运维人员讨论得最多的话题.

在本文, 笔者将会基于一个简单的golang demo, 通过Jenkins工具实现一个完整的镜像构建流程.

笔者会假设读者已经有一定的相关基础(一个能用的jenkins服务, 以及docker运行环境, 还有代码仓库和镜像仓库), 只会着重介绍关于jenkins任务的一些细节.

上周随手点开了自己的网站, 才发现SSL证书已经过期一周多了, 继而才想起这个网站已经上线一年了.

新手整出1GB的镜像, 说能跑就行. 老手看不下去给Dockerfile改了几行, 最后出来的镜像只有27MB, 一样能跑.

介绍HLS(HTTP Live Streaming), 以及自制m3u8播放链接的步骤

前言

自从开始了这个ELK专题之后, 笔者就一直都在Elastic Stack的框架下介绍里面的各种应用. 目前有覆盖到的有Elasticsearch, Logstash, Kibana, Beats(filebeat, metricbeat), 但是在真实的生产环境下, 做技术选型的时候往往还会依据现实的需要加入其它类型的中间件. 比如说, 为了进一步加强日志系统集群的健壮性, 我们还可以考虑增加一个消息队列的中间件.
在本文中, 我们就尝试着为ELK集群增加一个Kafka.

需要说明的是, 在前面的章节中介绍到的方案, 会把原始日志里面的json内容当做是纯文本去处理, 去到Logstash的时候再识别成json格式, 过程显得繁琐.

在最后的拾遗部分, 会再提供一个简便一点的方案.

前言

在运维的技术栈里面，说到监控系统，大多数人可能首先想到的对后台服务器的CPU、内存、网络流量、磁盘IO等性能指标监控起来。要是再深入一点，可能会再做一个日志监控，把各个事务的日志统计起来，可以跟踪各个事务的时间和数量的分布等等。

那假如，我们想更深入一层，想要知道各个API在处理事务的过程中在每个步骤上都花了多少时间呢？比方说，有一个接口GET /user_info/<user_id>，服务器在处理这个接口的时候需要从数据库上使用user_id查询用户的昵称，同时请求其他API得到玩家的排行榜信息。我们自然可以使用日志打点的方式把这些步骤都记录下来，再通过ELK的日志监控去完成，但这样无疑会增加大量的开发成本，而且很有可能需要反复打磨才能获得一个满足各个场景的通用标准。

而今天要说的Elastic APM(application performance monitoring)就是专门针对这种场景的通用解决方案。

发现内存告警，初级运维搞扩容，中级运维调参数，高级运维骂开发（误）。

前言

对刚刚接触Kubernetes的新手来说，在开始使用之前，有必要先理解一些关于Kubernetes的基本概念。

很多地方都会把Kubernetes和容器技术放在一起去讨论，但需要明确的是，Kubernetes是一个容器编排和管理的工具，为用户提供自动部署和容器监控等解决方案。目前在大多数主流的容器管理平台都支持Kubernetes，国外的有：OpenShift、Docker EE、AWS EKS、Rancher，而国内的则以腾讯云的TKE和阿里云的ACS为主流。

在下面的内容，我们主要来讨论一下在Kubernetes集群中的网络原理。

前言

笔者最初接触容器技术的时候，心中是充满疑问的。

“容器是一个进程吗？”

“和虚拟机有什么区别？”

“使用容器后，服务器内部到底发生了什么？”

……

后来，经过了较长的一段时间的学习，从实践到理论知识，才慢慢地摸索和总结出容器的工作原理。

跟往常的行文方式不同，这次会使用很多短句和换行，力求简明扼要地把概念说完。

毕竟，如果想要详细的话，我为什么不去看官方文档呢？ :-)

另外需要强调一点，本文讨论的是关于容器技术的通用解决方案，旨在简单介绍容器的设计思路和实现方式，可能会和现有的一些具体的容器方案有出入。