最近一个月大蕉断更了,主要就在做一些跟 k8s 相关的事情,就在昨天刚刚交付产品了一个版本,这几周几乎把大蕉榨干了。但是大蕉从来不是一个怕事的人,干就完了,一个当十个用,没什么大问题。
在三门等地区,都构建了全面的区域性战略布局,加强发展的系统性、市场前瞻性、产品创新能力,以专注、极致的服务理念,为客户提供网站制作、成都网站设计 网站设计制作按需设计网站,公司网站建设,企业网站建设,品牌网站建设,营销型网站,成都外贸网站建设,三门网站建设费用合理。
但是经过了几个月基于k8s写应用,我还是建议你别轻易尝试用 k8s ,这时候就有人问了,我看你前几个月还叫我们没事多学学 k8s 呢,为什么今天就说轻易别基于 k8s 写应用呢?
且听我细细说来。
基于 Docker 定义运行环境实在是太方便了,你可能没法像以前一样有一大堆的发布脚本排查发布环境的问题了。
这样线上环境太稳定,可能会裁剪一部分的开发运维人员。对于一个 Python 应用来说,以前我们需要安装 Linux,安装Python,安装 pip,安装相关的依赖库。可是对于 Docker 镜像定义方式 Dockerfile 来说。
- FROM python:3
- RUN pip install MySQL-python
这两行,Python 环境 和 MySQL 依赖就装好了,已经不需要害怕每个人的环境不一样,不需要害怕线上环境被谁搞坏了。运维可能会失业。
应用升级和回滚真的太方便了,你可能没法像以前一样搞一大堆的发布步骤。
加一个配置文件,换一个依赖包,升级一下linux内核版本,还要兼容一下。搞得每次发布都能由你自己搞。有了 k8s 你已经没这个机会了。这样你的价值会大大缩水。用 k8s 升级只需要这一行就够了。
- kubectl set image deployment your-app your-container=image:tag
这样 k8s 集群会对你的应用进行滚动升级,你不需要害怕升级的时候因为同时重启的问题导致服务不可用,它都帮你解决了。它升级的做法是先启动一个容器,确认这个容器正常服务了,再干掉原来的容器。
当然,发布出问题也是很常见的,以前的回滚要找发布包,回滚依赖,一堆事情做。现在有了 k8s ,回滚也变得简单起来。
- kubectl rollout undo deployment/your-app
回滚的步骤跟升级是一样的,会先启动原来镜像版本的容器,然后再干掉现在版本的容器。这一波操作,会导致你的存在感降低,你无法在发布的时候进行一顿疯狂操作了,很可惜,你很可能会被优化掉。
服务间暴露和调用真的太方便了,只能由你解决的调用 bug 可能一去不复返了。
想想这个场景,一个新人加入团队,面对代码里一堆的根据 ip 调用的逻辑,这个新人能怎么办呢?必然只能问你啊,这个 ip 是什么,另外一个 ip 又是什么?k8s 自带名字服务和负载均衡,如果只是在集群内调用,你终于不需要再用 ip + 端口的模式调用集群内的其他服务了,无论是 RPC 还是 HTTP 调用,都需要ip + 端口吧?很遗憾 k8s 集群默认并不会给你分配任何一个固定 ip 和端口,所有的 ip 和 端口都是动态分配的,你已经不能使用 ip 大法了。那么 k8s 是怎么做到的呢?
首先要明确一个 k8s 的 label 机制。我们俗称 label 名字叫 打标签,就是我会给我的应用(Deployment)打上一些标签,比如打一个标签名叫 app=my-app ,这个就类似给驴的脚底打上三颗痣。然后我再定义一个 Service ,不管这个应用长啥样,也不管它在哪里,只需要找标签为 app=my-app 的应用就完事了,就是说,无论你是剃光头还是留胡子,我都不管,我就找三颗痣,找到了你就是我的宠物。
很多很多的 magic ,等你你来发现,且听我细细说,如果你对 k8s 有兴趣,留言告诉我,我考虑写个实战系列。
如果你是靠各种邪术写魔法代码混职场的,我强烈建议你千万别用 k8s ,你很可能会混不下去。
网页标题:我建议你别基于k8s用写应用No.178
当前链接:http://www.shufengxianlan.com/qtweb/news16/397816.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联