sealos

Kubeadm 安装时的证书有效期设置为 1 年，虽说有 sealos 这样的不知名安装器以及各种方案来更新证书，但是对于像我一样经常跟不知来源的 Kubernetes 集群打交道的人来说，这个有效期就是达摩什么的利剑，不一定什么时候会砍到脖子上。如果能用 Prometheus 对证书有效期进行监控或者告警，就能更好地保护好自己的脖子了，ssl-exporter 就是这么个有趣的项目。 ssl-exporter 是个 Prometheus Exporter，能提供多种针对 SSL 的检测手段，包括：https 证书生效/失效时间、文件证书生效/失效时间，OCSP 等相关指标。下面用 API Server 证书检测来验证这一功能： 首先进行部署： apiVersion: v1 kind: Service metadata: labels: name: ssl-exporter name: ssl-exporter spec: ports: - name: ssl-exporter protocol: TCP port: 9219 targetPort: 9219 selector: app: ssl-exporter --- apiVersion: apps/v1 kind: Deployment metadata: name: ssl-exporter spec: replicas

原文链接： https://fuckcloudnative.io/posts/monitoring-calico-with-prometheus-operator/ Calico 中最核心的组件就是 Felix ，它负责设置路由表和 ACL 规则等，以便为该主机上的 endpoints 资源正常运行提供所需的网络连接。同时它还负责提供有关网络健康状况的数据（例如，报告配置其主机时发生的错误和问题），这些数据会被写入 etcd，以使其对网络中的其他组件和操作人员可见。 由此可见，对于我们的监控来说，监控 Calico 的核心便是监控 Felix ， Felix 就相当于 Calico 的大脑。本文将学习如何使用 Prometheus-Operator 来监控 Calico。 本文不会涉及到 Calico 和 Prometheus-Operator 的部署细节，如果不知道如何部署，请查阅官方文档和相关博客。 1. 配置 Calico 以启用指标 默认情况下 Felix 的指标是被禁用的，必须通过命令行管理工具 calicoctl 手动更改 Felix 配置才能开启，需要提前配置好命令行管理工具。 本文使用的 Calico 版本是 v3.15.0 ，其他版本类似。先下载管理工具： $ wget https://github.com/projectcalico/calicoctl

原文链接： https://fuckcloudnative.io/posts/lens/ Kubernetes 的桌面客户端有那么几个，曾经 Kubernetic 应该是最好用的，但最近有个叫 Lens 的 APP 改变了这个格局，功能比 Kubernetic 多，使用体验更好， 适合广大系统重启工程师装逼 。它有以下几个亮点： ① Lens 就是一个强大的 IDE，可以实时查看集群状态，实时查看日志流，方便排查故障。有了 Lens ，你可以更方便快捷地使用你的集群，从根本上提高工作效率和业务迭代速度。 日志流界面可以选择显示或隐藏时间戳，也可以指定显示的行数： ② Lens 可以管理多集群，它使用内置的 kubectl 通过 kubeconfig 来访问集群，支持本地集群和外部集群（如EKS、AKS、GKE、Pharos、UCP、Rancher 等），甚至连 Openshift 也支持： 只是与 Openshift 的监控还不太兼容。也可以很轻松地查看并编辑 CR： 有了 Lens，你就可以统一管理所有的集群。 ③ Lens 内置了资源利用率的仪表板，支持多种对接 Prometheus 的方式： ④ Lens 内置了 kubectl ，它的内置终端会确保集群的 API Server 版本与 kubectl 版本兼容，所以你不需要在本地安装 kubectl 。可以验证一下：

原文链接： Docker 容器优雅终止方案 作为一名系统重启工程师（SRE），你可能经常需要重启容器，毕竟 Kubernetes 的优势就是快速弹性伸缩和故障恢复，遇到问题先重启容器再说，几秒钟即可恢复，实在不行再重启系统，这就是系统重启工程师的杀手锏。然而现实并没有理论上那么美好，某些容器需要花费 10s 左右才能停止，这是为啥？有以下几种可能性： 容器中的进程没有收到 SIGTERM 信号。 容器中的进程收到了信号，但忽略了。 容器中应用的关闭时间确实就是这么长。 对于第 3 种可能性我们无能为力，本文主要解决 1 和 2。 如果要构建一个新的 Docker 镜像，肯定希望镜像越小越好，这样它的下载和启动速度都很快，一般我们都会选择一个瘦了身的操作系统（例如 Alpine ， Busybox 等）作为基础镜像。 问题就在这里，这些基础镜像的 init 系统 也被抹掉了，这就是问题的根源！ init 系统有以下几个特点： 它是系统的第一个进程，负责产生其他所有用户进程。 init 以守护进程方式存在，是所有其他进程的祖先。 它主要负责： 启动守护进程 回收孤儿进程 将操作系统信号转发给子进程 1. Docker 容器停止过程 对于容器来说， init 系统不是必须的，当你通过命令 docker stop mycontainer 来停止容器时，docker CLI 会将 TERM

sealos 最新版本支持 1.18.0 1 年证书 体验版本免费提供 http://store.lameleg.com 安装方式如下： 下载并安装 sealos, sealos 是个 golang 的二进制工具，直接下载拷贝到 bin 目录即可 wget https://github.com/fanux/sealos/releases/download/v3.2.0-alpha.0/sealos && \ chmod +x sealos && mv sealos /usr/bin 下载离线资源包 wget https://sealyun.oss-cn-beijing.aliyuncs.com/d551b0b9e67e0416d0f9dce870a16665-1.18.0/kube1.18.0.tar.gz 安装一个三 master 的 kubernetes 集群 sealos init --passwd 123456 \ --master 192.168.0.2 --master 192.168.0.3 --master 192.168.0.4 \ --node 192.168.0.5 \ --pkg-url /root/kube1.18.0.tar.gz \ --version v1.18.0 来源： oschina 链接： https://my.oschina.net/u

原文链接： https://fuckcloudnative.io/posts/lens/ Kubernetes 的桌面客户端有那么几个，曾经 Kubernetic 应该是最好用的，但最近有个叫 Lens 的 APP 改变了这个格局，功能比 Kubernetic 多，使用体验更好， 适合广大系统重启工程师装逼 。它有以下几个亮点： ① Lens 就是一个强大的 IDE，可以实时查看集群状态，实时查看日志流，方便排查故障。有了 Lens ，你可以更方便快捷地使用你的集群，从根本上提高工作效率和业务迭代速度。 日志流界面可以选择显示或隐藏时间戳，也可以指定显示的行数： ② Lens 可以管理多集群，它使用内置的 kubectl 通过 kubeconfig 来访问集群，支持本地集群和外部集群（如EKS、AKS、GKE、Pharos、UCP、Rancher 等），甚至连 Openshift 也支持： 只是与 Openshift 的监控还不太兼容。也可以很轻松地查看并编辑 CR： 有了 Lens，你就可以统一管理所有的集群。 ③ Lens 内置了资源利用率的仪表板，支持多种对接 Prometheus 的方式： ④ Lens 内置了 kubectl ，它的内置终端会确保集群的 API Server 版本与 kubectl 版本兼容，所以你不需要在本地安装 kubectl 。可以验证一下：

本文教你如何白嫖实现足够自动的开发测试交付，面向读者最好满足以下条件： 足够穷 足够懒 issueops? 听过chatops,gitops还没听过issueops，顾名思义issueops就是在讨论issue的时候把ops的事给干了，讨论问题就把问题给解决，美哉。 kubernetes项目issue或者PR中会经常看到这样的东西： 类似 /kind feature 这样的指令是给机器人看的，这里就要介绍一位非常勤奋的小伙伴了： 他叫k8s-ci-robot,我想没有谁的贡献有他多了吧，这可不是刷出来的，都是实打实的工作量： 收到指令后robot就忙着打标签，验证提问题的有没有cla认证，分配review代码的人等： 然后懒汉们review完代码就又吩咐机器人测试： 小伙伴就一顿操作梦如虎的干了好多事情还不拿年终奖： 以上，企业是不是发现养一个robot胜似招10个员工，是不是比疫情期间面向周报编程程序员靠谱多了~ Prow Prow 就是robot的实现，原理非常简单，就是通过github webhook去监听github产生的事件，分析里面的指令去执行对应的job，它能干的几个重点的事： 执行任务，特别是测试任务 合并代码，你可能觉得这不就是点个按钮的事吗？其实不是，比如一个bug的修复可能要合并到很多个版本中，做起来枯燥且恶心，而且很多时候还是希望合并代码时能做些额外的事

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> > 原文链接： Istio 1.4 部署指南 Istio 一直处于快速迭代更新的过程中，它的部署方法也在不断更新，之前我在 1.0 版本中介绍的安装方法，对于最新的 1.4 版本已经不适用了。以后主流的部署方式都是用 istioctl 进行部署，helm 可以渐渐靠边站了~~ 在部署 Istio 之前，首先需要确保 Kubernetes 集群（kubernetes 版本建议在 1.13 以上）已部署并配置好本地的 kubectl 客户端。 1. Kubernetes 环境准备 为了快速准备 kubernetes 环境，我们可以使用 sealos 来部署，步骤如下： 前提条件 下载 kubernetes 离线安装包 下载 最新版本sealos 务必同步服务器时间 主机名不可重复 安装 kubernetes 集群 $ sealos init --master 192.168.0.2 \ --node 192.168.0.3 \ --node 192.168.0.4 \ --node 192.168.0.5 \ --user root \ --passwd your-server-password \ --version v1.16.3 \ --pkg-url /root/kube1.16.3.tar.gz