sig-kubernetes
sig-kubernetes copied to clipboard
cloudnativeto
云原生社区 Kubernetes SIG
拆解：（三个人） 2. 实例化scheduler过程 源码分享 【书8.3.3】#62（把调度算法的注册和实例化部分重点介绍下，包括如何从配置文件指定调度算法【书8.3.1 + 自由发挥】） 3. 事件管理器EventBroadcaster的介绍和在scheduler中的作用和注册过程分【书8.3.4】 4. HTTP和HTTPS部分代码，重点可以强调下怎么给scheduler加API接口【书8.3.5】 新增： 事件管理器EventBroadcaster的介绍和在scheduler中的作用和注册过程分【书8.3.4】 HTTP和HTTPS部分代码，重点可以强调下怎么给scheduler加API接口【书8.3.5】 优先级降低 scheduler参数介绍【书8.1】#60 命令行参数解析源码分享 【书8.3.2】#61
把调度算法的注册和实例化部分重点介绍下，包括如何从配置文件指定调度算法【书8.3.1 + 自由发挥】
## 分享内容 在进行源码阅读的时候，会经常看到资源 Status 里面有 `Phase`、 `State`、 `Conditions` 这几个字段，仔细看会发现它们都是描述资源的状态，那它们到底有什么区别呢，不仔细研究还真是会让人傻傻分清楚。 这里首先给出个人的理解 Conditions 是一组详细状态，描述的是资源当前以及过去的状态；Phase 和 State 描述的是资源的当前状态，这两个的用法是一样的，至于用哪个则根据个人喜好了，Phase、State 的取值来自于 Condtions。 Conditions 已经成为一个用于收集资源的详细状态的标准机制，Conditions 应该是可扩展的，常用一个数组、切片来实现，典型的 condition 的结构如下： | 字段名称 | 描述 | | -------------------- |...
大家好，源码研习社一期活动已经结束，感谢大家的积极参与。这一期我们以《Kubernetes源码剖析》第5章作为参考，深入的学习 Kubernetes 客户端库 client-go 的源码。 回想本次活动的初衷，我们做到了。 > 搭建一个由热爱学习、注重个人成长的一帮小伙伴们组成的小组，以Kubernetes为主题，每个人都能从中学到知识，帮助自己成长与进步。 ## 学习过程 第一期活动共五周，根据学习要求精读《Kubernetes 源码剖析》和Client-go源码。 计划原定一周一小节内容，后由于源码难度以及学习深度，改为二周一小节。要求每一节都产出一篇200字以上的笔记或随想，最后1周为总结周。将自己的笔记或随想帖链接直接回复在 研习社事项跟踪 上。  每一节都有很多同学提交自己精读研究源码后的思考总结文章。  ## 本期收获 1. 我们组建了微信群，陆陆续续有382名同学加入，群内气氛活跃，每日都有同学交流讨论Kubernetes源码相关知识，互相学习帮助。 2. 有30多位同学提交了学习笔记，很多笔记深入分析源码细节，每一篇读起来都收获颇丰。其中还有几篇投稿到社区，已发布在官网和公众号上。 3. 很多同学不仅用文字记录下了自己的思考，还画了构思精巧有细节有全局的剖析图，搭配着图看源码很容易理解。 这些成果都是因为大家积极的学习热情。 * 感谢所有参与活动，在群里活跃交流讨论的382名同学。 *...
hi，大家好，第一周的活动结束了，以下同学笔记经过Maintainer审核，其总结的内容很优秀，特此鼓励: Github ID | Wechat ID | 笔记链接 -- | -- | -- AbyssViper @AbyssViper | LTX-AbyssViper | https://app.yinxiang.com/fx/86f469c5-e395-4c05-b33b-0a3baf1acf13 lianghao208 @lianghao208 | roy-lianghao208 | https://blog.csdn.net/qq_17305249/article/details/107802411 janeliul @janeliul | 娟-JaneLiuL |...
``` // Generate final API pod status with pod and status manager status apiPodStatus := kl.generateAPIPodStatus(pod, podStatus) ... // Record the time it takes for the pod to become running....
## 问题描述 在 apiserver 启动过程中，会为不同的资源注册不同的 api。如：kubeApiServer负责内置资源的 api 创建，extensionServer 负责 crd 这种外部资源的 api 创建（只负责 apiextensions.k8s.io/v1 这个组的资源的 api 创建），aggregatorServer 负责 apiregistration 的api创建（只负责 apiextensions.k8s.io 这个组的资源的 api 创建）。 但在我们写 CRD 时，会自定义 CR 的 api...
