1
hwdef 2022-07-13 10:34:19 +08:00 1
可以不 code ,只使用,就做个运维。k8s 目前生态不错,很多需求都有比较好的实现。
如果遇到了没办法满足你需求的开源项目,那就可以自己 code 了。。无非就是 cni ,cri ,csi ,serviec mesh ,各种 operator 。只要能让你们的业务平稳的运行在 k8s 上,,能较好的开发迭代,,code 不 code 不重要 |
2
idblife 2022-07-13 10:36:50 +08:00 11
yaml 工程师
|
3
Hanggi 2022-07-13 10:45:43 +08:00 1
其实你可以把自己定位为 DevOps 程序员,目前很火的一个概念。
|
4
nicholasxuu 2022-07-13 10:47:54 +08:00 1
集群监控警报之类的完善。写 operator 插件服务处理 yaml 里的问题。
比如自动动态增减容器有 hpa 可以解决,但是怎么知道 hpa 是否有合理发挥作用呢?怎么知道其他人管理的服务是否有难以发现的配置错误呢?如何减少资源申请过高导致的服务器浪费呢?如何尽早知道节点资源快不够了呢?节点资源管理可以用弹性节点解决,但是用弹性节点的话,如何确定弹性节点有按需的增加和减少呢? 还有,如何保证任何天灾(服务器坏了)人祸(有人发了配置错误的服务)发生时,尽可能少的需要运维人员介入(等人处理要时间,还要确定有人值班),并且尽可能的避免损失?(自动检测到问题并恢复) |
5
alexsunxl 2022-07-13 10:56:00 +08:00 1
写 crd 呗。 还有被下游推的一些配置需求。
还有手动搬运社区的新代码。 就是说: 想把 k8s 升级大版本,几乎不太可能。但是又有需要的新功能,就只能搬运源码了。 |
6
alexsunxl 2022-07-13 10:58:11 +08:00 1
|
7
isno 2022-07-13 11:02:46 +08:00
恭喜,荣升"SRE 工程师"称号。
|
8
dolphintwo 2022-07-13 11:12:21 +08:00 4
平时都在 delete pod
|
9
a398058068 2022-07-13 11:20:49 +08:00
开发
|
10
a398058068 2022-07-13 11:22:18 +08:00
k8s 集成 istio 做微服务 。 纯运维已经搞不定了所以只能 我们全栈工程师来搞。 开发 k8s 之外的时间开发业务应用。
|
11
jorneyr 2022-07-13 13:48:01 +08:00
用 Go 开发 K8S Operator 。
|
12
zr8657 2022-07-13 13:55:51 +08:00
我这三十来个节点,K8S 没事的时候我就写增删查改
|
13
Frankcox 2022-07-13 14:32:05 +08:00 1
Operator 、client-go 等等
|
15
novolunt 2022-07-13 17:16:56 +08:00
v2 划水
|
16
4771314 2022-07-13 18:50:14 +08:00 1
智能客服
随时处理业务问题 |
17
Cola98 2022-07-13 19:10:46 +08:00 1
之前是做和 K8S 有关的运维,主要是用 kubespray 做部署,升级之类的。然后现在的话用 client-go 写周边的测试
|
18
9 2022-07-13 19:38:33 +08:00
@alexsunxl 我能理解规模大了后,和业务协调沟通 k8s 兼容的成本会很高。可是搬运源码的事情实在是太蛋疼,运维成本太高,迟早运维不动。规模大,跟不能升级版本不是强相关的。
|
19
sukidesuka 2022-07-14 09:51:13 +08:00
用 kubebuilder 框架写自动化运维程序
|
20
pepesii 2022-07-14 10:06:19 +08:00 1
|
23
dnsjia 2022-07-29 12:55:17 +08:00
|