openshift-sdn官方建议使用network-operator工具进行网络部署，实际上在该项目中我们甚至可以扒出一套基本完整的部署模板。基于这套模板我们可以直接部署openshift-sdn。

kube-router是一套开源网络方案，基于bgp协议构建路由，从而构建整个容器集群网络，它使用ipvs实现了k8s的service网络，并使用ipset和iptables工具实现了networkpolicy。

与以往IaaS服务场景下，针对虚拟机、网卡对象的安全组规则不同，networkpolicy是k8s原语。因此，在k8s场景下，进行网络安全规则的规划时，用networkpolicy能做到更加的灵活和自动化。举个例子：

最近看到一篇公众号讲了nginx-ingress-controller的应用。下面有人评论如何做日志持久化， 我们设计了一个较为无侵入的方案，通过这个方案可以将nginx-ingress-controller的日志输出，不论是accesslog还是klog库输出的日志，都能进行重定向落盘和轮转、清理。 我们发现这个日志持久化方案基本可以应对绝大多数的容器应用...

我们知道k8s的service一般都会有clusterIP和port，每个cluster-ip:port的组合对应着一个服务，kube-proxy（这里以iptables为例）为这个服务生成一组iptables规则，分发到对应的后端和后端端口。比如：

学习目的了解sriov网卡的正确读取姿势，学习相关的golang开源库配置文件看这部分代码前我们先看看官方提供的一个配置文件范例： {代码...} 这里selectors是用来过滤机器上的pci网络设备的，只要当前check的网卡的属性包含于配置文件里对应属性的数组，就会被选入。vendors表示厂商号，devices表示设备号，drivers表示驱...

本篇将继续深入学习kubebuilder开发，并介绍一些深入使用时遇到的问题。包括：finalizer、控制器对CRD的update status、kubebuilder注释等。并且会分享一些在开发过程中使用的小技巧

使用场景当我们需要进行服务端认证，甚至双向认证时，我们需要生成密钥对和服务信息，并使用ca对公钥和服务信息进行批准签发，生成一个证书。我们简单描述下单向认证和双向认证的场景流程在单向认证场景中：服务端会将自己的证书和公钥告知客户端客户端向CA查询该证书的合法性，确认合法后会记录服务端公钥客户端会与服...

建议版本：docker 18.06k8s 1.14 (如果要开发删除时的webhook，需要升级到1.15)1. Install安装kubebuilder执行下面的脚本： {代码...} 即可安装kustomize2. Dev创建project使用kubebuilder前，必须要确保本地的go版本为1.11或以上，开启了go module （export GO111MODULE=on）我们在GOPATH下新建一个目录。并在其中执行k...

在kubernetes 1.14版本中， Local Persistent Volumes(以下简称LPV)已变为正式版本（GA），LPV的概念在1.7中被首次提出（alpha），并在1.10版本中升级到beat版本。现在用户终于可以在生产环境中使用LPV的功能和API了。

在早先的k8s版本中，kubelet代码里提供了networkPlugin,networkPlugin是一组接口，实现了pod的网络配置、解除、获取，当时kubelet的代码中有个一个docker_manager，负责容器的创建和销毁，亦会负责容器网络的操作。而如今我们可以看到基本上kubelet的启动参数中，networkPlugin的值都会设置为cni。

1、下载模板wget https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/kubeadm/1.7/calico.yaml

最近在产品新版本的服务发现和负载均衡方案上遇到了一个问题，在尽量不改动原生k8s使用方式和代码前提下，对service又重新复习了一遍，略有体会。

1.9中，kube-scheduler仍然是作为一个“plugin”放在k8s代码中，在k8s根目录下的plugin目录中，cmd/kube-scheduler目录是其编译入口，pkg/scheduler目录是其主要核心代码。如图：

通过向apiserver发送一个patch node 的请求，为这个node增加一个自定义的资源类型，用于以该资源的配额统计和相应的QoS的配置。

k8s调度器会将pod调度到资源满足要求并且评分最高的node上。我们可以使用多种规则比如：1.设置cpu、内存的使用要求；2.增加node的label，并通过pod.Spec.NodeSelector进行强匹配；3.直接设置pod的nodeName，跳过调度直接下发。

network policy顾名思义就是对pod进行网络策略控制。 k8s本身并不支持，因为k8s有许多种网络的实现方式，企业内部可以使用简单的flannel、weave、kube-router等，适合公有云的方案则有calico等。不同的网络实现原理（vethpair、bridge、macvlan等）并不能统一地支持network policy。

Guaranteed 。该策略下，pod.spec.containers[].resources中会存在cpu或memory的request和limit。顾名思义是该容器对资源的最低要求和最高使用量限制。如果我们配置了limit，没有配置request，默认会以limit的值来定义request。具体的配置可以参考以前的这篇笔记。