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。具体的配置可以参考以前的这篇笔记。

docker的使用者十分广泛，不止有网易蜂巢，daocloud，时速云这类的已经成熟化的公有云服务，许多中小型企业内部也在试图将docker容器应用到内部的运维工作中。

本文主要介绍如何用kubernentes挂载rbd目录。以及其中遇到的问题。有关ceph和rbd相关请自行百度。 如何创建 参照github上kubernetes/examples/rbd/ 目录下的范例，我们可以创建一个挂载rbd存储的容器。前提是： 当前网络中有一个ceph服务器 slaver节点上要安装ceph client。 从ceph服务器上获取client，monitor等关键信...

rancher 自带了一套网络方案，可以实现跨机器的docker容器互联。其原理大致是：在每个机器上通过docker启动一个路由容器，将docker容器启动时的ip定义为10.42网段，并在iptables中将10.42网段的请求转发到路由进程的监听端口，进行udp的封装和解封。这么看来其原理与flannel一样都是隧道技术，都是通过一个程序进行封包...

好久没有更新了，今天在接到一个部署任务时，要求在集群中某几个机器上部署，查了一下github，有这方面的相关文档，翻译过来记录一下，有兴趣的同学也可以直接去github看官方文档

最新一版的kubernetes release中我们看到了一个令人欣喜的特性：Autoscaling。它实现了replicationcontroller中pod的横向自动扩容。以下是摘自官方文档的相关内容：

写在前面 最近在研究docker集群（kubernetes）的监控，为了彻底弄清楚，简单看了一点源码。这里分享一下我学到的东西。 docker api: stats 首先是docker的api，stats的具体使用场景如： {代码...} 可以获取docker机器上某一个容器的状态，该请求的response会持续的写响应报文回来（每秒一次） {代码...} 参数stream默认...

这句的意思是给这个rc的每个pod分配cpu额度的最低要求是1.0（即1个CPU核心），内存的最低要求是1.0Gi，对CPU的限制是不能超过1.2个核心，内存则是1.1Gi。当我们执行create命令的时候，若scheduler组件检查各个nodes发现没有满足1个空闲cpu核心和1Gi空闲内存的机器，那么这个pod就不能被创建，若rc要创建3个pod，整个集群...

之前的文章里我们为了成功使用heapster而自建了证书：进入master机器的/var/run/kubernetes/目录，执行如下的几个命令：

会自动生成一个apiserver.crt和apiserver.key文件，所在目录是/var/run/kubernetes/,并且程序启动后会发现，有一个默认的serviceaccount，这种模式下我们创建的resource都会有一个默认的serviceaccount。

注：本案例在我的部署环境下是可行的，但不保证在所有环境下都可行。我尽可能讲得直白而详细，因为我自己也才刚开始接触，已经做过深入研究的可以浏览，若有什么错误，烦请指正，感激不尽！