柳清风的专栏

我发布在公司网站上，在此连接记录一下：http://college.creditease.cn/#/detail/15/176

上一篇blog讲解了一下gc的整个流程。后面介绍了删除sandbox。但sandbox怎么删除还是没有讲清楚，在此详细展开说一下。

kubelet是负载干活的组件，它会定期的清理多余死掉的容器和镜像，这篇blog基于kubernetes1.7.6的代码，关于gc的深入源码分析 好了，先看gc是随着kubelet启动而启动的pkg/kubelet/kubelet.go，func (kl *Kubelet) StartGarbageCollection() { loggedContainerGCFailure := fal

昨天遇到一个docker拉取镜像报错的问题，后来查询到是镜像的鉴权有问题，下面就和我跟着kubernetes 1.7.6 的代码看看整个过程。首先看拉取镜像的地方， pkg/kubelet/kuberuntime/kuberuntime_image.gofunc (m *kubeGenericRuntimeManager) PullImage(image kubecontainer.ImageS

之前1.4的源码分析已经讲过调度的过程，现在载对一些细节补充一下。首先是k8s会加载哪些资源调度算法呢，其实它支持两种，一种是配置文件，一种是默认代码中指定的，下面看看plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go里面默认的调度算法，一个是筛选func defaultPredicates() sets.String {

最近在给k8s 1.8添加磁盘调度的时候，又撸了一遍k8s的相关的源码，之前看过我源码分析的那个是k8s 1.4版本的，1.8版本还是有点变化的。 先看看kubelet上报机制，这个是kubelet的心跳机制，定时上报节点状态，默认是10s，时间可以设定 在kubelet创建的时候就已经创建了节点状态的收集方法 pkg/kubelet/kubelet.go里面NewMainKubelet方法k

在开始源码分析之前先说一下filebeat是什么？beats是知名的ELK日志分析套件的一部分。它的前身是logstash-forwarder，用于收集日志并转发给后端（logstash、elasticsearch、redis、kafka等等）。filebeat是beats项目中的一种beats，负责收集日志文件的新增内容。当前的代码分支是最新的6.x的代码。 先看我们服务启动配置文件的一个例子，

上一篇介绍了bridge的实现，这里介绍一下calico的实现。和上一篇的结构一样的，先看add然后看del，具体添加网卡的代码如下：func cmdAdd(args *skel.CmdArgs) error { // Unmarshal the network config, and perform validation conf := NetConf{} if err :

之前介绍CNI基本操作，现在介绍一个bridge的实现。 它也实现了创建和删除接口。 先看创建接口：func cmdAdd(args *skel.CmdArgs) error { n, cniVersion, err := loadNetConf(args.StdinData) if err != nil { return err } if n.Is

CNI(Container Network Interface)容器网络接口。CNI只专注解决容器网络连接和容器销毁时的资源释放，提供一套框架，所以CNI可以支持大量不同的网络模式，并且容易实现。 执行CNI需要传入一下变量# 添加或者删除网卡CNI_COMMAND=ADD/DEL# 容器的IDCNI_CONTAINERID=xxxxxxxxxxxxxxxxxxx# 容器网络空间主机映射路

如果大家对kubernetes组件以及架构相关分析，可以看我之前的源码阅读，今天只从一个函数分析容器的启动过程，这个函数就是SyncPod，这个是创建kubelet里面最核心的一个函数了。这个方法分为五步：// 1. Compute sandbox and container changes.// 2. Kill pod sandbox if necessary.// 3. Kill an

Service AccountService Account概念的引入是基于这样的使用场景：运行在pod里的进程需要调用Kubernetes API以及非Kubernetes API的其它服务。Service Account它并不是给kubernetes集群的用户使用的，而是给pod里面的进程使用的，它为pod提供必要的身份认证。kubectl get sa --all-namespacesNAME

kubernetes对于第三方存储本身没有管理，只是使用存储，先看一下首先是存储插件的初始化，在这个方法里面，通过Init方法初始化func (pm *VolumePluginMgr) InitPlugins(plugins []VolumePlugin, host VolumeHost) error { pm.mutex.Lock() defer pm.mutex.Unlock()

其实kube-proxy的代码本身并不复杂，只是有个细节容易被大家忽略，大家可能都知道它有轮询的复杂均衡策略，是通过iptables实现的，那它是怎样控制平均转发的呢？iptables有个random的模块支持，那怎样控制权重呢？ 看代码，一步一步分析 { tablesNeedServicesChain := []utiliptables.Table{utiliptables

之前写了很多kubernetes源码阅读的文章，今天介绍一下kubernetes开发入门，kubernetes提供了一个client-go，它里面封装了kubernetes的相关操作，分为两种情况，在集群内核集群之外 先说一下集群内package mainimport ( "fmt" "time" metav1 "k8s.io/apimachinery/pkg/apis/me

这是flannel最后一篇，我原本不准备介绍UDP，因为这种方案的网络损耗实在是太多，大约一半损耗，vxlan大约是30%损耗。但基本的UDP使用我还是想和大家分享一下的，主要是tun设备的使用。 像UDP的RegisterNetwork和VXLAN一样，我就不单独说了backend/udp/udp_network.go。func (n *network) Run(ctx context.Con

之前一直介绍flannel的使用，现在正是进入代码讲解，看看flannel是如何实现的，先看启动func main() { flag.Set("logtostderr", "true") // 解析参数 flag.Parse() if flag.NArg() > 0 || opts.help { fmt.Fprintf(os.Stderr, "Usage

kubernetes的 Aggregated API是什么呢？它是允许k8s的开发人员编写一个自己的服务，可以把这个服务注册到k8s的api里面，这样，就像k8s自己的api一样，你的服务只要运行在k8s集群里面，k8s 的Aggregate通过service名称就可以转发到你写的service里面去了。 这个设计理念： 第一是增加了api的扩展性，这样k8s的开发人员就可以编写自己的API服务

这篇blog名字起的搞得和我写论文一样，xxxx的设计与实现。其实这个东西原理很简单，kubernetes的hpa使用的是heapster，heapster是k8s那帮家伙在搞的，所以k8s还是喜欢自己搞的东西，所以k8s的hpa默认使用的heapster，但在业内，还有一个比heapster更好的监控方案，那就是prometheus。如果按照写论文的方式，我这边应该分别介绍一下k8s和promet

invalid容器创建的容器有个创建的时长的选项age，测试环境发现有的容器时间是invalid，通过代码查看原来是时间不对 因为每个kubelet是定时上报的，上报是基于本地当前时间的。wildfly-rc-1l9qv 0/1 ContainerCreating 0 <invalid>解决办法，在每个机器安装ntp服务。保持每个节点...

在生产环境中，docker和flannel都是通过systemd管理的，发生了一个奇怪的事情，当重启网络插件flannel的时候，docker daemon也发生了重启，这个很奇怪，按道理是各自独立运行的。细查日志，当重启flannel时候systemd也把docker重启了。# systemctl list-dependencies docker.service docker.serv...

在kube-proxy日志里面有很多报错E0813 10:47:18.983433 454071 proxier.go:722] conntrack return with error: error looking for path of conntrack: exec: "conntrack": executable file not found in $PATHE0813 10:4...

之前还有一些环境部署上面的事情没有交代，这里补充完毕apiserver参数修改--runtime-config=autoscaling/v2alpha1=true "--requestheader-username-headers=X-Remote-User --requestheader-group-headers=X-Remote-Group --requestheade...

之前的blog分析过k8s 1.4的apiserver代码，今天和大家分享一下k8s 1.7.6关于apiserver启动的代码。先上一个大图，花了好几个小时！ 上面的图是整个启动的完整流程，关于api注册的地方。我打印了具体日志 上面installAPIResources有三个输入源分别是下面三个：extensionsversion:apiextensions.k8s.io/

kubernetes qos资源分类QOS是kubernetes保证服务质量的一个模块。 先介绍两个基本概览 * 可压缩资源：CPU 在压缩资源部分已经提到CPU属于可压缩资源，当pod使用超过设置的limits值，pod中进程使用cpu会被限制，但不会被kill。不可压缩资源：内存 Kubernetes通过cgroup给pod设置QoS级别，当资源不足时先kill优先级

之前的blog分析了kubelet启动pod的流程，那么pod一旦启动了，谁去上报状态呢？还是回到之前代码syncLoopIteration，这个里面有四个输入源，第一次创建接受到configch add这个没有问题，然后是启动容器，此时会上报到容器正在创建的状态到apiserver，还会接收到收到configch reconcile。那么关键的来，什么时候上报成功的呢？ pkg/kubelet

前面两篇文章已经介绍了整体的内容，下面就已对青云的存储为例，先提供一个Provision的实现func (c *volumeProvisioner) Provision(options controller.VolumeOptions) (*v1.PersistentVolume, error) { glog.V(4).Infof("qingcloudVolumeProvisioner Pr

上一篇介绍创建存储pv的流程，那个有个存储需要挂载到容器里面才能被使用，下面还需要一个通用的接口felx去将存储挂载到容器里面。 kubernetes存储的使用和协助需要分别实现挂载和解挂的接口 kubernetes下面pkg/volume/volume.gotype Attacher interface { // 挂载存储到主机 Attach(spec *Spec, nodeN

kubernetes发展到1.7以后，就朝着平台去开发了，上一个讨论的点是kubernetes把metrics单独出去，成为一个kubernetes的监控标准，这个我们以后再慢慢说，先看存储这个孵化的项目。github.com/kubernetes-incubator/external-storage第三方存储对接。 它和上一篇介绍的custom-metrics-apiserver项目一样都是孵化

之前的两篇blog介绍了kubelet启动pod的过程，但没有介绍存储挂载的过程，这里还是补充说一下， 首先看kubelet启动时候// Start volume managergo kl.volumeManager.Run(kl.sourcesReady, wait.NeverStop)看Run启动方法，如下：func (vm *volumeManager) Run(sourcesReady

上一篇blog讲解到到从apiserver获取需要更新的pod的信息，然后传入syncLoopIteration。那么需要变化的pod不是只有上面上面三个，因为本地的pod状态可能发生变化，譬如本地的容器退出，那么怎么去让本地退出的容器重新启动呢？答案在于另一个输入源码plegch这个channel中。 下面看看syncLoopIteration这几个输入源func (kl *Kubelet) s

现在还剩下最后一东西没有解决了，就是一个查询的接口，提供一个prometheus转接的地方。第一篇blog已经介绍了通过自定义指标采集器调用custom-metrics接口。现在看看这个接口的实现，首先得有这样一个接口 这个是基于k8s的一个孵化项目： github.com/kubernetes-incubator/custom-metrics-apiserver 他就是提供一个自定义服务

如果看过之前的blog，大家都肯定都已经知道kubelet是负责真正启动容器的干活的，其实k8s的代码里面最复杂的其实是kubelet，而不是无脑的大脑apiserver，它基本是依靠etcd完成很多工作。 那么kubelet怎么去启动pod，何时去启动pod呢？我先从kubelet启动的地方说起。 先看上面这张图，这张图详细的介绍了kubelet启动pod的三个来源，分别是apiserve

上一篇介绍了

其实flannel的东西基本都说完了，还有一个功能点由于和kubernetes紧密结合的，所以在这里解释一下。相信大家都还记得之前写的创建SubnetManagerfunc newSubnetManager() (subnet.Manager, error) { if opts.kubeSubnetMgr { return kube.NewSubnetManager()

上一篇介绍的vxlan模式，本篇还想介绍一个host-gw模式，顾名思义，就是主机网关模式。这个和calico的路由模式中主机网关是一样的，只不过没有BGP罢了。 先介绍一下怎么使用，然后分析了源码。先设置一下网络模式etcdctl set /flannel/network/config '{"Network": "192.168.0.0/16","SubnetLen": 24,"Subnet

上一篇介绍controller manager的watch机制，还有一点没有说清楚的就是添加的回调方法（AddEventHandler）怎样被触发的，方法的回调和之前介绍kubelet的store回调稍有不同，它的回调是通过FIFO queue完成的。看代码：func (s *sharedIndexInformer) Run(stopCh <-chan struct{}) { defer u

上一篇 介绍了kubedns服务启动过程，现在看服务怎样运行。分为两个主要部分，第一个是怎么提供DNS解析服务，第二是怎样同步更新sevice信息。那下面开始讲解。 服务怎么同步呢？必须是listwatch，继承kubernetes一套API体系，我以后要说的ingress同步，也是这样的。下面看代码：//servicekcache.ResourceEventHandlerFuncs{

之前写了一篇kubernetes之controller manager启动，如果感兴趣可以看这篇博客 今天深入聊一下watch机制。从启动CM(controller-manager)启动开始细说 代码是基于kubernetes 1.6的，这里启动和以前的版本稍有差别,老版本是一个一个分别启动，现在统一到一起：func newControllerInitializers() map[string]

上一篇介绍了kubeadm的init这篇主要讲解join，它们我们用kubeadm最常用的两个组件。 和init的一样，首先还是配置解析参数，创建join结构体func NewJoin(cfgPath string, args []string, cfg *kubeadmapi.NodeConfiguration, skipPreFlight bool) (*Join, error) {