深入剖析Kubernetes
张磊
Kubernetes社区资深成员与项目维护者
立即订阅
22715 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (5讲)
开篇词 | 打通“容器技术”的任督二脉
免费
01 | 预习篇 · 小鲸鱼大事记(一):初出茅庐
02 | 预习篇 · 小鲸鱼大事记(二):崭露头角
03 | 预习篇 · 小鲸鱼大事记(三):群雄并起
04 | 预习篇 · 小鲸鱼大事记(四):尘埃落定
容器技术概念入门篇 (5讲)
05 | 白话容器基础(一):从进程说开去
06 | 白话容器基础(二):隔离与限制
07 | 白话容器基础(三):深入理解容器镜像
08 | 白话容器基础(四):重新认识Docker容器
09 | 从容器到容器云:谈谈Kubernetes的本质
Kubernetes集群搭建与实践 (3讲)
10 | Kubernetes一键部署利器:kubeadm
11 | 从0到1:搭建一个完整的Kubernetes集群
12 | 牛刀小试:我的第一个容器化应用
容器编排与Kubernetes作业管理 (15讲)
13 | 为什么我们需要Pod?
14 | 深入解析Pod对象(一):基本概念
15 | 深入解析Pod对象(二):使用进阶
16 | 编排其实很简单:谈谈“控制器”模型
17 | 经典PaaS的记忆:作业副本与水平扩展
18 | 深入理解StatefulSet(一):拓扑状态
19 | 深入理解StatefulSet(二):存储状态
20 | 深入理解StatefulSet(三):有状态应用实践
21 | 容器化守护进程的意义:DaemonSet
22 | 撬动离线业务:Job与CronJob
23 | 声明式API与Kubernetes编程范式
24 | 深入解析声明式API(一):API对象的奥秘
25 | 深入解析声明式API(二):编写自定义控制器
26 | 基于角色的权限控制:RBAC
27 | 聪明的微创新:Operator工作原理解读
Kubernetes容器持久化存储 (4讲)
28 | PV、PVC、StorageClass,这些到底在说啥?
29 | PV、PVC体系是不是多此一举?从本地持久化卷谈起
30 | 编写自己的存储插件:FlexVolume与CSI
31 | 容器存储实践:CSI插件编写指南
Kubernetes容器网络 (8讲)
32 | 浅谈容器网络
33 | 深入解析容器跨主机网络
34 | Kubernetes网络模型与CNI网络插件
35 | 解读Kubernetes三层网络方案
36 | 为什么说Kubernetes只有soft multi-tenancy?
37 | 找到容器不容易:Service、DNS与服务发现
38 | 从外界连通Service与Service调试“三板斧”
39 | 谈谈Service与Ingress
Kubernetes作业调度与资源管理 (5讲)
40 | Kubernetes的资源模型与资源管理
41 | 十字路口上的Kubernetes默认调度器
42 | Kubernetes默认调度器调度策略解析
43 | Kubernetes默认调度器的优先级与抢占机制
44 | Kubernetes GPU管理与Device Plugin机制
Kubernetes容器运行时 (3讲)
45 | 幕后英雄:SIG-Node与CRI
46 | 解读 CRI 与 容器运行时
47 | 绝不仅仅是安全:Kata Containers 与 gVisor
Kubernetes容器监控与日志 (3讲)
48 | Prometheus、Metrics Server与Kubernetes监控体系
49 | Custom Metrics: 让Auto Scaling不再“食之无味”
50 | 让日志无处可逃:容器日志收集与管理
再谈开源与社区 (1讲)
51 | 谈谈Kubernetes开源社区和未来走向
答疑文章 (1讲)
52 | 答疑:在问题中解决问题,在思考中产生思考
特别放送 (1讲)
特别放送 | 2019 年,容器技术生态会发生些什么?
结束语 (1讲)
结束语 | Kubernetes:赢开发者赢天下
特别放送 | 云原生应用管理系列 (1讲)
基于 Kubernetes 的云原生应用管理,到底应该怎么做?
深入剖析Kubernetes
登录|注册

23 | 声明式API与Kubernetes编程范式

张磊 2018-10-15
你好,我是张磊。今天我和你分享的主题是:声明式 API 与 Kubernetes 编程范式。
在前面的几篇文章中,我和你分享了很多 Kubernetes 的 API 对象。这些 API 对象,有的是用来描述应用,有的则是为应用提供各种各样的服务。但是,无一例外地,为了使用这些 API 对象提供的能力,你都需要编写一个对应的 YAML 文件交给 Kubernetes。
这个 YAML 文件,正是 Kubernetes 声明式 API 所必须具备的一个要素。不过,是不是只要用 YAML 文件代替了命令行操作,就是声明式 API 了呢?
举个例子。我们知道,Docker Swarm 的编排操作都是基于命令行的,比如:
$ docker service create --name nginx --replicas 2 nginx
$ docker service update --image nginx:1.7.9 nginx
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《深入剖析Kubernetes》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(39)

  • 周龙亭
    是因为envoy提供了api形式的配置入口,更方便做流量治理

    作者回复: 是的

    2018-11-26
    25
  • Geek_zz
    居然看一遍就记住了这节课的原理
    2018-10-15
    21
  • mazhen
    有个疑问,在envoy-initializer的“控制循环”中获取新创建的Pod,这个Pod是否已经在正常运行了?
    Initializer 提交patch修改Pod对象,Kubernetes发现Pod更新,然后以“滚动升级”的方式更新运行中的Pod?

    作者回复: 不会啊。注意看apiserver的流程图,initializer发生在admission阶段,这个阶段完成后pod才会创建出来。

    2018-10-15
    10
  • Lis
    老师好,课后作业的方式非常棒,可否在下一节课的开始先总结一下课后作业呢?
    2018-11-09
    8
  • huan
    又查了下envoy的设计,感觉它支持热更新和热重启,应该很适合声明式规则的开发范式,这可以看做一种优势,相比而言,nginx的reload需要把worker进程退出,比较面向命令

    作者回复: 这确实是一个因素

    2018-10-15
    6
  • 虎虎❤️
    老师,用声明式api的好处没有体会太深刻。
    如果在dosomething中merge出新的yaml,然后用replace会有什么缺点?
    好像在这篇文章中仅仅提到声明式的可以多个客户端同时写。除此之外,还有其他优点吗?
    也就是说修改对象比替换对象的优势在哪?

    作者回复: istio不就是例子?系统里完全可以有好几个initializer在改同一个pod,你直接replace了别人还玩不玩了?

    2018-10-15
    6
  • Alex
    Initializer与新的pod 在git merge冲突了该怎么解决?

    作者回复: 就不会注入成功了

    2018-11-14
    5
  • Chumper
    磊哥竟然穿插了istio的讲解,后续有没有计划讲讲knative呢

    作者回复: knative没啥特别的,暂时就不给篇幅了

    2018-10-15
    5
  • 虎虎❤️
    kubectl apply 是通过mvcc 实现的并发写吗?

    作者回复: 是啊

    2018-10-16
    4
  • Frank_balabala
    老师你好!
    ”如果你对这个 Demo 感兴趣,可以在这个 GitHub 链接里找到它的所有源码和文档。这个 Demo,是我 fork 自 Kelsey Hightower 的一个同名的 Demo“

    我看这个initializer的plugin都已经没了,现在是不是都要写Admission hook了? https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#

    例如这个 https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/main.go
    2019-05-12
    3
  • 混沌渺无极
    dynamic admission control有点像防火墙的DNAT,数据包即将进入路由表的瞬间被修改了目的地址,这样路由表就对数据包的修改[无感]。
    patch就像多人使用git来进行文件的"合并型"修改。

    作者回复: 就是这么回事儿

    2018-10-16
    3
  • 虎虎❤️
    老师,为什么修改对象可以多个客户端同时写,而替换不行?感觉还差一层窗户纸,老师帮我捅破:)
    或者有什么资料可以让我更深入理解下吗?

    作者回复: 你的错误之处在于,patch数据只可能被PATCH API认识。你总想着让replace也能用patch数据,那replace不就成了patch api了?

    2018-10-15
    1
    3
  • Dillion
    我对声明式API的理解是:apiserver与etcd在不断维护者某个对象各个属性字段。修改对象状态的方式是修改这个对象的属性。也就是,对象的属性作为API,暴露给用户,用户通过修改对象属性,实现对对象的修改。
    2018-10-15
    3
  • DJH
    请教老师,Initializer和Preset都能注入POD配置,那么这两种方法的适用场景有何不同?

    作者回复: preset相当于initializer的子集,比较适合在发布流程里处理比较简单的情况。initializer是要写代码的。

    2018-10-15
    3
  • 羽翼1982
    所以这个问题的答案是什么呢?
    我的理解是Envy性能更高,占用系统资源更少

    作者回复: 编程友好的api,方便容器化,配置方便

    2018-11-27
    2
  • 王天明
    按GitHub里的启动的pod envoy-initializer-xxxx报状态crashloopbackoff,日志显示backoff restarting failed container,不知道大家有没有遇到这种情况
    2018-11-05
    2
  • 闫飞
    服务网格最初是由linkerd项目提出概念的,lstio是另外一个后起之秀,使大家都关注到了边车代理模式和服务治理的新方法的巨大威力。文中应该笔误写错为微服务了。

    不过瑕不掩瑜,本节写的极其精彩和深入浅出。

    作者回复: service mesh is just a fancy way of microservice

    2019-01-16
    1
  • divfor
    多路并发写我的理解是patchBytes := strategicpatch.CreateTwoWayMergePatch(pod, newPod)的时候pod的状态未必等于patch时候的pod状态,所以要先记下差异,中间给予其他写者机会,最后自己patch的时候只管自己记下的差异,而不动其他写者的部分。万一跟其他写者冲突了就失败吧,由人来解决
    2019-01-05
    1
  • cqc
    除了能想到envoy作为通用的sidecar可以提供更为完善的微服务治理能力之外,在代理网络流量方面,感觉其他两个软件也能做到。求解答^.^

    作者回复: 可以尝试了解一下envoy的api

    2018-10-17
    1
  • gotojeff
    Hi 老师
    ‘’‘有个疑问: name 为envoy的configmap是在哪里定义的呢?
    2018-10-16
     作者回复
    文中不是贴出来了?
    ’‘’
    configmap模板中的 metadata - name是envoy-initializer,但是在下面的container volumes中的configmap name是envoy,我的疑惑是这是2个不同的configmap吧?后者是在其他地方定义的?

    作者回复: 哦哦,这个忘记贴了。没错,这个configmap需要使用envoy的配置文件创建出来,配置文件网上可以下到。kubectl create configmap envoy —from-file envoy.json

    2018-10-17
    1
收起评论
39
返回
顶部