zyxpaomian的博客

最近接了个活，可能需要写一套私有云的云管平台，简单梳理了下思路，我认为所谓的云管平台，即是将传统的数据/资产运维管理，转变为数据/资产的运营，所以主要操作还是以展示和反馈为主。

所有的kubernetes管理平台，都会用到TTY的功能，既通过前端直接进入到容器内部，这是一个交互式的操作，或者说是一个流式操作，简单的http协议肯定不能满足这个需求，使用websocket就能很好的满足这个需求。既然决定了使用websocket作为前端进入容器的方式，那么可以看看后端是如何进入容器的。

golang有一个好处是 操作kubernetes很方便，来看看基于clientset 如何进行封装

后端框架的选择面比较大，由于不涉及复杂的调度/分布式管理等场景，所以后端选用一个标准的web server即可，比如gin, iris, beego等等，因为正好最近在看iris的一些项目，所以就选用了irsi+corba的框架进行后端开发 。

对于集群的管理和平台的管理，权限很重要

用了rancher,用了kube-dashboard，要么觉得前者太重，要么觉得后者太轻，如何兼顾这2者？那就自己开发吧

最近有一个 场景是基于某封邮件进行回复，这样可以在收件箱内形成一个完整的邮件链，比如进行倒计时的提醒，自动邮件回复等情况还挺实用的，日常对邮件的处理主要还是发邮件进行告警等，使用imap进行回复的场景还是挺少见的，所以简单记录一下。

由于Centos7的EOL问题，业内有很多需求需要将Centos7进行升级，CloudLinux开展的一项支持 RHEL 衍生产品主要版本之间迁移的计划的项目-ELevate。Leapp 实用程序 (opens new window) 和一些支持从非 RHEL 操作系统迁移的补丁 (opens new window) 用于执行升级。该工具可以在升级前进行相关的环境检查，如rpm相关依赖，内核模块的差异，不同版本间的模块差异等，最大程度上的减少升级风险。

日常使用golang开发，以及日常需要运维Kubernetes，所以一直不太习惯使用zookeeper或者nacos，反而使用etcd会多一点，有时候需要写一些分布式系统，使用etcd也可以很好的解决分布式系统一致性的问题。总的来说，我觉得etcd在以下3个领域的使用，很好用。

相比方法二来说，方法一的步骤比较简单，但实际操作的时候，可能会存在做完快照的同时有用户数据写入的情况，从而再一次导致Revision不一致，此外，之前提到奇数节点一旦发生故障，会将集群变成偶数节点，从而在短期内产生脑裂的风险，所以在发现故障后，要赶快进行修复。算是比较粗暴的修复方法，就是将当前集群的问题member 从集群内剔除，然后删除节点信息，然后将该节点重新加入到集群，依靠etcd 自身的同步机制，将数据同步。方式1的方法需要重新新增节点，如果存在数据量较大，可以采用备份恢复的方式。

现在无论是公有云还是私有云，虚拟机还是裸金属，在交付过程中或多或少总有很多定制化的需求，比如密码定制，磁盘挂载，agent启动等等。有些场景可以将定制化的需求放在镜像内，但对于一些业务种类，规模较多的场景来说，频繁更新镜像并不是一个好事情，cloud-init 的方式就会比较合理，通过启动时候注入的方式，完成了主机的初始化，且就目前来说，cloud-init已经成为了云主机初始化的一个行业标准，并几乎适用于所有主流的Linux发行版。

为什么innodb以及monggo等会喜欢使用B+Tree的数据结构进行数据存储呢？

背景魔都啥情况也算众所周知了，每天5点多起床加购物车，抢菜，失败的循环已经持续了2个月了，作为一个IT从业者，只能想办法从代码层面来解决抢菜难的问题了。目前通过代码抢菜的方式主要分为2种，第一种是测试们都很熟悉的，利用手机自动化测试的方式，进行自动抢菜，说白了就是通过代码模拟你在手机端按键，可供选择的框架有Appium和Calabash或AthRun等，主要因为这几个对IOS和Android都支持比较好。该方式也挺方便，且安全，因为对于抢菜平台来说，你最多也就是个筋膜枪选手，而且是个，但性能相对会差一点

今天来撸一个简单的ingress-controller, 用于了解ingress-controller的实现机制。完整的代码在 simple-ingress-controller基本逻辑ingress说的简单点就是url 和 service的对应关系，相当于nginx的upstream，而ingress-controller就是用来管理这些“upstream”的，可以理解为是个动态的反向代理。基于“动态反向代理”这个概念，实现一个简单的ingress-controller需要2部分，即 动态 + 反

现象：某日某服务通过代理访问某公网地址：xxx-test.hhfx.cn，出现502 的情况，但直接访问该网站可以正常完成请求，查看502报错时间段的日志，出现了SSL_do_handshake() failed (SSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv1 alert handshake failure的报错。分析目前内网服务调用公网接口，使用的是Nginx正向代理的方式进行的，且默认使用4层代理，仅做TCP层面的端口转

之前写了一个简单的webhook 的tls server，并且写了一个简单的validate的api 用于实现资源的拦截。之前有提到webhook有两类，第二类就是mutatingadmissionwebhook，即对资源进行修改，仔细想想不会太意外，比如istio本质上不就是mutatingadmissionwebhook么，在启动的时候直接sidecar方式插入一个container，然后通过该container进行各类服务收集/治理，那练手的话可以自己插入一个redis 容器，模拟istio的side

补充好基础知识后，上手实践才是最快的学习方法，所以先写一个validateadmission练练手。模拟一个生产需求，假设生产环境所有的deployment不允许单点，即副本数量不能少于2，如果少于2则不允许创建，且多个Kubernetes集群都有类似需求，那么这个场景用webhook实现就非常简单。先上一下自己写的demo地址webhook demo，可以对照查看思路之前有提过webhook的调用逻辑，结合当前场景，大致上是以下几个步骤：创建一个tls 的webserver, 做好路由，路由绑定

什么是webhookKubernetes 通过rbac进行权限控制，实现了哪些account对哪些资源具有哪些权限的控制，但它并不是万能的, 因为rbac控制的操作权限类型是有限的，需要再进行一些细化的权限管控就无从下手了，比如需要限制一些controller只能从制定的harbor进行image的下载，比如需要限制一些controller只能使用指定范围的端口号等，所幸Kubernetes在各个方面都可以进行一些自定义的开发，而webhook就是用来实现类似需求的。webhook官网介绍先看下官网的

ClientSet的基本使用日常运维一般使用kubectl进行资源的查看，创建，销毁等，对接一些自动化运维平台的话可能需要通过一些其他方法，k8s官方提供的方式就是通过clientset进行操作，举个Goclient的例子, 当然其他语言也有类似的sdk封装，为了贴合源码，主要还是学习go的:package mainimport ( "flag" "fmt" "os" "path/filepath" "context" metav1 "k8s.io/apimachinery/pkg/

声明式API 与资源对象一般我们在k8s里声明一个新的资源对象，一般会先写一个声明式的yml, 里面对该资源进行描述/声明，最后apply/create一下进行资源的创建。apiVersion: batch/v1kind: Jobmetadata: name: demo namespace: default.......比如上面那个资源文件，就包含了资源的几个基本要素：资源类型(Resource): jobs(一般是kind的小写复数形式)资源组(Group):这里的batch就