Technology

Fluentd配置文件最佳实践

Fluentd负责Kubernetes中容器日志的收集工作, 以Daemonset形式运行在每一个节点上. 下面这个配置是在多个生产集群使用的配置, 经过多次调优的. 有一些关键的配置增加了配置解释说明. 目前使用问题不大. 持续更新配置中…

Kubernetes 服务器配置和规划建设要求

新建集群的第一步就是要规划服务器、网络、操作系统等等, 下面就结合我平时的工作经验总结下相关的要求, 内容根据日常工作持续补充完善:

服务器配置 #

kubernetes 集群分为控制节点和数据节点, 它们对于配置的要求有所不同:

控制面 #

节点规模Master规格
1~5个节点4核 8Gi(不建议2核 4Gi)
6~20个节点4核 16Gi
21~100个节点8核 32Gi
100~200个节点16核 64Gi

系统盘40+Gi,用于储存 etcd 信息及相关配置文件等

...

MetalLB概念安装配置和使用

官方文档

为什么使用? #

Kubernetes没有提供适用于裸金属集群的网络负载均衡器实现, 也就是LoadBalancer类型的Service. Kubernetes 附带的网络负载均衡器的实现都是调用各种 IaaS 平台(GCP、AWS、Azure ……)的胶水代码。 如果您没有在受支持的 IaaS 平台(GCP、AWS、Azure…)上运行,LoadBalancers 在创建时将一直保持在pending状态。

裸金属集群的运维人员只剩下两个方式来将用户流量引入集群内: NodePortexternalIPs. 这两种在生产环境使用有很大的缺点, 这样, 裸金属集群也就成了 Kubernetes 生态中的第二类选择, 并不是首选.

MetalLB 的目的是实现一个网络负载均衡器来与标准的网络设备集成, 这样这些外部服务就能尽可能的正常工作了.

...

Linux 控制组(cgroups)和进程隔离

控制组(cgroups)是内核的一个特性,它能限制/统计/隔离一个或者多个进程使用CPU、内存、磁盘I/O和网络。cgroups技术最开始是Google开发,最终在2.6.24版本的内核中出现。3.15和3.16版本内核将合并进重新设计的cgroups,它添加来kernfs(拆分一些sysfs逻辑)。cgroups的主要设计目标是提供一个统一的接口,它可以管理进程或者整个操作系统级别的虚拟化,包含Linux容器,或者LXC。

分析告警 kubernetes 节点 load 过高问题

负载过高分析 #

通过 linux 提供的几个命令可以从不同的纬度分析系统负载。

vmstat #

这命令能从一个系统的角度反应出服务器情况,报告虚拟内存统计信息,报告有关进程、内存、分页、块的信息 IO、陷阱、磁盘和 CPU 活动。看个例子:

1
2
3
4
5
6
7
8
$ vmstat --wide --unit M 5
procs ----------------memory---------------- ---swap--- -----io---- ---system--- ---------cpu--------
 r  b     swpd      free      buff     cache   si   so    bi    bo     in   cs     us sy  id  wa  st
 1  1        0    127691      1535     73572    0    0     0     3      0    0     2   1  97   0   0
93  0        0    127674      1535     73573    0    0     0    80   49267 67634   5   1  94   1   0
 0  2        0    127679      1535     73573    0    0     0    66   38537 56283   3   1  95   1   0
 2  2        0    127738      1535     73574    0    0     6    86   41769 61823   5   1  93   2   0
 2  0        0    127729      1535     73574    0    0    18    18   41002 59214   4   1  95   0   0

命令以及输出解释:

...

在 kubernetes 中找出使用 jdk9 及以上版本的应用

近日, Spring Cloud (SPEL) 中发现 RCE 0-day 漏洞, 为了排查 kubernetes 中所有存在安全威胁的应用. 特地开发了一个小工具来寻找。该工具基于 golang&client-go 开发, 程序会找出当前集群中所有 Running 的 pods, 然后逐个进入容器,执行 java -version 命令,将命令输出打印到文件中,使用编辑器进行查找检索即可。

Harbor 双主复制解决方案实践

既然使用了外部的服务, 那么高可用的压力自然而然的转移到了外部服务上. 我们一开始采用的外部的 NFS 共享存储服务, 由于我们团队实际情况, 我们暂时还不能保证外部存储的高可用. 同时, 鉴于我们对镜像服务高可用的迫切需求, 决定调研新的 Harbor 的高可用方案.

在 kubernetes 中找出过度使用资源的 namespaces

我们知道, 在 kubernetes 中, namespace 的资源限制在 ResourceQuota 中定义, 比如我们控制 default 名称空间使用 1核1G 的资源. 通常来讲, 由于 kubernetes 的资源控制机制, .status.used 中资源的值会小于 .status.hard 中相应资源的值. 但是也有特例. 当我们开始定义了一个较大的资源限制, 待应用部署完毕, 资源占用了很多之后, 这时调低资源限制. 此时就会出现 .status.used 中的值超过 .status.hard 中相应值的情况, 尤其是内存的限制.