深入剖析 Kubernetes
张磊
Kubernetes 社区资深成员与项目维护者
116705 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 57 讲
再谈开源与社区 (1讲)
结束语 (1讲)
深入剖析 Kubernetes
15
15
1.0x
00:00/00:00
登录|注册

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

思考题
Kubernetes编程范式
Kubernetes声明式API的重要性
Istio项目与声明式API
用YAML文件代替命令行操作
声明式API与Kubernetes编程范式

该思维导图由 AI 生成,仅供参考

你好,我是张磊。今天我和你分享的主题是:声明式 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
像这样的两条命令,就是用 Docker Swarm 启动了两个 Nginx 容器实例。其中,第一条 create 命令创建了这两个容器,而第二条 update 命令则把它们“滚动更新”成了一个新的镜像。
对于这种使用方式,我们称为命令式命令行操作
那么,像上面这样的创建和更新两个 Nginx 容器的操作,在 Kubernetes 里又该怎么做呢?
这个流程,相信你已经非常熟悉了:我们需要在本地编写一个 Deployment 的 YAML 文件:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了声明式API在Kubernetes编程中的重要性,并以Istio项目为例,阐述了声明式API在微服务治理方面的应用。作者首先对比了Docker Swarm的命令式命令行操作和Kubernetes的YAML文件操作,指出了命令式配置文件操作与声明式API的区别。随后,详细解释了kubectl apply命令的作用,以及其与kubectl replace命令的区别,强调了声明式API的重要性。接着,通过Istio项目的实例,阐述了声明式API在实际使用中的重要意义。文章还介绍了Kubernetes中的Dynamic Admission Control功能,以及Istio项目如何利用Initializer实现自动注入Envoy容器的操作。通过实例和技术原理的讲解,深入浅出地阐述了声明式API的概念及其在Kubernetes编程中的重要性。整篇文章突出了声明式API对Kubernetes编程范式的重要性,以及在微服务治理方面的应用,为读者提供了深入的技术理解和实践应用的指导。文章内容涵盖了Kubernetes编程范式的重要性、声明式API的应用、Istio项目的实际案例以及技术原理的讲解,为读者提供了全面的技术视角和实践指导。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入剖析 Kubernetes》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(61)

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

    作者回复: 是的

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

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

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

    作者回复: 是啊

    2018-10-16
    2
    46
  • swordholder
    有个疑问,在envoy-initializer的“控制循环”中获取新创建的Pod,这个Pod是否已经在正常运行了? Initializer 提交patch修改Pod对象,Kubernetes发现Pod更新,然后以“滚动升级”的方式更新运行中的Pod?

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

    2018-10-15
    3
    45
  • 混沌渺无极
    dynamic admission control有点像防火墙的DNAT,数据包即将进入路由表的瞬间被修改了目的地址,这样路由表就对数据包的修改[无感]。 patch就像多人使用git来进行文件的"合并型"修改。

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

    2018-10-16
    2
    42
  • DJH
    请教老师,Initializer和Preset都能注入POD配置,那么这两种方法的适用场景有何不同?

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

    2018-10-15
    2
    25
  • huan
    又查了下envoy的设计,感觉它支持热更新和热重启,应该很适合声明式规则的开发范式,这可以看做一种优势,相比而言,nginx的reload需要把worker进程退出,比较面向命令

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

    2018-10-15
    5
    23
  • lucasun
    Initializer不是一直bata然后废弃了嘛,istio用的是MutatingAdmissionWebhook吧

    作者回复: Istio 现在是admission hook。这部分功能变化太多了,最好是自己写个sidecar operator 来管理。

    2020-03-03
    3
    19
  • Alex
    Initializer与新的pod 在git merge冲突了该怎么解决?

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

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

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

    2018-11-27
    16
收起评论
显示
设置
留言
61
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部