陈日志 发布的文章

Kubernetesg官网中有这么一张图,使用 kubeadm 引导的 Kubernetes 集群,使用负载均衡器将kube-apiserver 暴露给工作节点。

如果你使用过rkerke2等 Kubernetes 发行版,你会发现,他们并没有使用负载均衡器也能实现 kube-apiserver 的高可用。

你有没有思考过 rkerke2等 Kubernetes 发行版是如何做 kube-apiserver 的高可用的呢?

要搞清楚这个问题,我们看一下 kubelet 是如何连接 kube-apiserver 的就有答案了。

- 阅读剩余部分 -

查看证书有效期

kubeadm安装的kubernetes集群查看证书有效期

kubeadm certs list

这个命令将列出所有当前使用的证书,包括其名称、状态和过期时间。

rke安装的kubernetes集群查看证书有效期

for i in /etc/kubernetes/ssl/*.pem; do echo $i; openssl x509 -noout -dates -in $i; done

rke2安装的kubernetes集群查看证书有效期

控制节点:

for i in /var/lib/rancher/rke2/server/tls/*.crt; do echo $i; openssl x509 -in $i -noout -dates; done

for i in /var/lib/rancher/rke2/server/tls/*/*.crt; do echo $i; openssl x509 -in $i -noout -dates; done

工作节点:

for i in /var/lib/rancher/rke2/agent/*.crt; do echo $i; openssl x509 -in $i -noout -dates; done

- 阅读剩余部分 -

背景

RacketMQ 5.X 的发布,向云原生迈出了一大步。从官方的文档中,我们可以看到其中最大的一块变化是新增了 Proxy 模块,新旧版本架构对比如下:

  • RocketMQ 4.X 架构

    rocketmq4.x-arch.png

  • RocketMQ 5.X 架构

    rocketmq5.x-arch.png

在 RocketMQ4.X 的时候,深入使用过 RocketMQ 的人很多都可能遇到一个问题,RocketMQ 在复杂网络下是有缺陷的,比如说网上就有很多人问 RocketMQ 如何同时对内网和外网提供服务。得到的答案可能是让你修改brokerIP1、brokerIP2,brokerIP1 指向公网IP,brokerIP2 指向内网IP。但是这样并不能解决问题,因为 NameServer 始终会向客户端返回 brokerIP1 的地址,并不是真正解决了内外网的问题。

- 阅读剩余部分 -

背景

使用GitLab的时候,开发者是可以随意设置其用户名和邮箱的。

git config --global user.name "abc"
git config --global user.email "123"

像我这样设置,代码依然可以正常提交,在gitlab上查看的时候显示的用户名是“abc”。

git-commit-username.png

Git本身精神就是协作,是自由、平等,而非集权式的代码库。这样设计也没毛病,但是在公司的代码管理中,这样就很不好,尤其是在开发 Leader review 代码的时候,如果没有正确配置用户名可能都不知道这代码是谁写的。

- 阅读剩余部分 -

背景

大多数团队都会使用 GitLab 作为代码管理平台,通常采用的都是通过单个安装包(Omnibus)进行安装,安装包内已捆绑了运行 GitLab 所需的所有服务与工具。若是你所在的团队人数比较多或者为了解决单机部署所带来的单点故障问题,那么可用的方案有以下两种:

  • 多台主机安装 Omnibus 包,通过 /etc/gitlab/gitlab.rb 配置文件开启/禁用所需组件,控制组件的数量来达到高可用部署和性能需求
  • 通过 Helm Chart 部署到 Kubernetes 中

现在对比一下各个方案的优劣:

  • 单机部署

    • 优点:维护简单
    • 缺点:存在单点故障、不足以支撑1000+用户使用
      gitlab-single-server.png

- 阅读剩余部分 -