zyxpaomian的博客

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

之前写了一个简单的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就

Big Picture环境Kubernetes 版本：v 1.19.7golang 版本：1.16.2(因为m1,不得不使用如此高版本的go…)目录结构.├── BUILD.bazel -> build/root/BUILD.root├── CHANGELOG├── CHANGELOG.md -> CHANGELOG/README.md├── CONTRIBUTING.md├── LICENSE├── LICENSES├── Makefile -> build/

HPA(Horizontal Pod Autoscaler)K8S的水平扩缩容其实也是由一个独立的控制器管理的, 也就是HPA。API 细节HPA 属于 autoscaling API 组的资源组kubectl api-versions | grep autoscalautoscaling/v1autoscaling/v2beta1autoscaling/v2beta2autoscaling/v1：只支持基于CPU指标的缩放。autoscaling/v2beta1：支持Reso

Big Picturecalico 释放IP的逻辑相比分配IP的逻辑要简单很多，老样子，先画个图:然后看代码，从cmdDel开始看:func cmdDel(args *skel.CmdArgs) error { ...... handleID := utils.GetHandleID(conf.Name, args.ContainerID, epIDs.WEPName) ...... if err := calicoClient.IPAM().ReleaseByHandle(

背景生产要把网络插件换成calico，对于IP的分配方法有点存疑，花了2天看下了calico-ipam的源码，学习下calico的IP分配逻辑，对比生产环境，看看有没有明显的坑。calico比较突出的一点是可以指定单个pod的ip，也可以指定一个RS的网段，但实际用的比较少，首先不可能单个pod部署，一个rs指定一个ippool的意义并不是很大，所以主要看下自动分配的代码逻辑，代码其实不是很多，但几个概念挺绕的，根据目前的了解，简单画了一个流程图:IPAM的入口还是老三样，分IP 从cmdAdd开始

亲和性 && 反亲和性在默认的K8S调度中，一般经过预选和优选即可完成调度，但是生产的实际使用中，考虑到部分业务的特殊性，一般会手动进行一些"指定"， K8S 把这些"指定"分为nodeAffinity(节点亲和性)、podAffinity(pod 亲和性) 以及 podAntiAffinity(pod 反亲和性), 这在调度过程中，称之为亲和性调度，亲和性调度可以分成软策略(preferredDuringSchedulingIgnoredDuringExecution )和硬策略(re

Big Picture在调度过程中，会有各种预选和优选算法，在经过了那么多道门槛之后，一个POD才能完成调度，提供服务，在调度过程中，假设有一个很重要的系统服务调度失败了，导致了故障，为了避免这种情况，我们可以对该应用设置一个相对较高的优先级，在调度失败后，将一些优先级相对较低的不是那么重要的应用”挤走“，这就是K8S调度的优先级和抢占的作用。优先级K8S有一个专门的API对象，就是优先级，比如:apiVersion: scheduling.k8s.io/v1beta1kind: Priority

Big PictureK8S的调度说实话一般没啥人改，因为一般的体量，基于K8S内置的算法基本就满足了，但对于大体量和特殊场景来说，还是很有必要进行修改的，比如假设有好几种业务场景的pod，需要按需要调度到不同的rack上，传统做法当然可以对Node进行label，然后在不同业务的pod上做match，同样的，也可以修改调度器，在调度的时候自动进行调度，类似的场景有点像openstack的filter模块，所以理解K8S的调度还是非常有必要，毕竟先了解了，才能修改。informer机制,调度的开始K8

什么是Qos众所周知，k8s的资源分配主要基于container的resources进行限制，其中又分为了requests和limits 两个字段，分别表示容器的基本所需资源以及最大限制，该2个字段的最大作用，就是为K8S的调度以及资源回收服务。Qos是啥，假设一条通道只能容纳100人，当我们有120人需要疏散的时候，如何让老人小孩先走，Qos就是将老人小孩的重要级调高，从而保障老人小孩可以在第一批通过。回到K8s，当一台Node的资源即将耗尽，如何保障我们的Node上的系统服务(比如calico的da

基本概念容器的网络交互，大致上分为overlay和underlay 两大类，underlay 一句话总结就是底层传统网络，服务底层服务器/网络设备的互联互通， overlay 一句话总结就是基于隧道技术在underlay上的叠层网络，流量需要跑在underlay上。Flannelflannel作为K8S最常见的一个非官网CNI，支持3种网络实现： UDP, VXLAN, HOST-GW, 学习一下用于理解传统意义上的overlay网络方案还是非常好的。UDP模式UDP模式利用了Linux的一个特殊

calico 架构组件清单组件版本k8s集群1.14calico-kube-controller3.8.9calico-node3.8.9calicoctl3.8.9docker18.09.6etcdv3其中calico-node 包含了相同版本的CNI（即calico-cni 和calico-ipam）基本架构图基本架构基于calico-BGP 的网络互联方式，BGP 互联地址 && Node管理IP都在同一

K8S的自定义存储插件和K8S的网络不太一样，K8S的网络只有CNI一种接口暴露方式，所有的网络实现基于第三方进行开发实现，但存储的内置实现就多达20多种，#K8S目前支持的插件类型#。但内置的往往不满足定制化的需求，所以和CNI 一样，K8S 也暴露了对外的存储接口，和CNI 一样，通过实现对应的接口方法，即可创建属于自己的存储插件，但和CNI 有点区别的是，K8S的存储插件的自定义实现方式，有FlexVolume 和 CSI 两种，两者的差别可以看做是新老功能的差异，但目前为止，FlexVolume

RBACRole：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限, 但Role只对指定的namespace下的资源生效。ClusterRole: 集群橘色，同样也是一组规则，定义了一组对 Kubernetes API 对象的操作权限， ClusterRole 可以对所有namespace下的资源生效。Subject：被作用者，既可以是“人”，也可以是“机器”，也可以是你在 Kubernetes 里定义的“用户”。RoleBinding：定义了“被作用者”和“角

生产上线prometheus后遇到了一个监控覆盖度的问题，prometheus 是通过server端配置里的targets来获取监控对象的，targets的获取又是依赖discovery模块进行获取的，prometheus默认支持很多的discovery的模块，以2.19版本为例，他就支持了如下sd的方式: "github.com/prometheus/prometheus/discovery/azure" "github.com/prometheus/prometheus/discovery/cons

背景CNI 这东西搞容器的运维想必都不陌生,要知道，kubernetes的设计之初是不包含网络的，网络这玩意每家公司有每家公司自己的玩法，对各个公司来说，没有那种大一统的完美方案，只有最适合自己的方案，所以，kubernetes在设计的时候，没有设计统一的网络方案，只提供了统一的容器网络接口，Container Network Interface，也就是所谓的CNI。CNI 和 IPAM一般说的CNI都是包含IPAM的，但其实2个功能是分开实现的。CNI用于实现网络构建(network部分,网

Why Helm日常操作kubernetes 的编排，一般都是以下几个步骤:创建namespace->创建对应的rs(deployment,statefulset)->创建对应的service->创建对应的Ingress可能有些app还需要pv/pvc或者secretmap之类。纯靠手工管理简直反人类，所以一般的云平台都会直接调用client-go进行各类resource的创建，通过提前预置的信息作为模板调用K8S API，实现统一管理，该做法比较正规，但是对于云平台的开发者来说，