跳至主要内容

博文

目前显示的是 一月, 2019的博文

我为什么不喜欢 CoreOs/Operator

Table of Contents 1. Operator 是什么 2. 一 3. 二 4. 三 5. 四 6. 五 7. 六 8. 七 9. 参考资料 1  Operator 是什么 如果你还没有看过 coreos 的 operator,可以到  这里  进行一个短暂的阅读 2  一 目前的 operator 是一个处于实验性、尚不成熟的运维经验流程化的方法论 3  二 operator 在文档中描述的能力: 打包、部署、管理 kubernetes 应用 在文档中列出了几个项目: etcd-operator rook prometheus vault 4  三 拿 etcd-operator 来说,他实际上做了什么呢 1.输入 版本与集群规模创建/删除一个 etcd 集群 2.调整一个集群的大小 3.在 pod 意外丢失时重现创建 4.oprator 在被删除后的恢复 (与 4 相同) 5.升级 etcd 的版本 6.备份和恢复 etcd 集群 看起来是符合 operator 中描述的能力,但实际呢 实际上他仅能满足字面上的最小能力 如果我需要的的是仅在特定几台机器(小于集群规模且无统一标签)上的 etcd 集群呢? 如果我要在更换 etcd 的证书呢 如果我要将备份的数据存储到非 aws 的存储呢 有太多他做不到的事情了 5  四 可能会有人认为,太多的自定义需求只要实现一个符合自己需求的 operator 不就可以了吗? 那么思考下面几个问题 1.谁来写这个 operator 2.写好了 operator 之后就能满足未来所有的需求吗 3.这个 operator 如何进行交接 6  五 假设有这样一个人,有着丰富的运维经验,又愿意遵循着这样的规范来完成一个 operator 在一个人可以将运维经验抽象成一个 operator 这么长的时间内,他连一个用来简化操作的的脚本都没有写过吗? 当他学习了 operator 的 sdk 然后,将自己平时使用的脚本中的逻辑以 operator 的方式放到了集群中 新来的同事问他,这个服务该怎么运维啊 他会说 A.你看一下这个服务 operator 的使用文档 B

k8s 源码阅读 -- eviction

Table of Contents 1. 前言 2. 资料 3. 代码详解 3.1. 代码参考 3.2. 详细 1  前言 在某些情况下 k8s 会出现 evicted 的 pod, 然而这并不在  pod 的生命周期 中.这就是 k8s 的驱逐机制。 当机器的一些资源(内存、磁盘)过小时,为了保证 node 不会受到影响,会将 pod 驱逐至其他的机器上 2  资料 可以在  这里看到相关资料 来看一下代码中,驱逐策略是怎样实现的 3  代码详解 3.1  代码参考 kubernetes release-1.10 3.2  详细 pkg/kubelet/apis/kubeletconfig/v1beta/default.go 定义了这几个默认值作为阈值 pkg/kubelet/kubelet.go kubelte 初始化了 eviction manager 在 runtime 相关模块被加载时,eviction manager 被加载进来 开始了 evict 相关的控制循环 接下来是 evict 真正工作的代码 代码目录是 pkg/kubelet/eviction/ 主要看该目录下的两个文件 eviction manager.go  helpers.go pkg/kubelet/eviction/eviction manager.go Start 是 evict manager 的入口 这里是一个死循环 循环中的主要函数是 synchronize 用来清理 pod、同步信息。这个就是今天的主角 先看一下 synchronize 的参数 diskInfoProvider podFunc diskInfoProvider 是一个接口,用来提供磁盘的信息,作为是否发生驱逐的依据。实际函数在  pkg/kubelet/stats/  下 synchronize 中仅用到了 HasDedicatedImageFs podFunc 用来获取一个待检查的 pod 列表,实际函数在 pkg/kubelet/kubelet pods.go 首先检查 imagesfs, 数据从 cadvisor 中获取 获得容器