前段时间在这个视频中分享了 https://github.com/bregman-arie/devops-exercises 这个知识仓库。
这次继续分享里面的内容,本次主要以 k8s 相关的问题为主。
k8s 是一个开源应用,给用户提供了管理、部署、扩展容器的能力,以下几个例子更容易理解:
yaml
文件,告诉 k8s
我的预期是什么,其中同步变化的过程全部都交给 k8s 去完成。其实就是我们常说的声明式 API
k8s
,这种情况通常是比较传统的业务,没有必要使用 k8s
。不过这些功能运维自己写工具也能实现。
k8s
对容器有着健康检测,比如使用启动探针、存活探针等,或者是容器 OOM
后也会重启应用尝试修复。service
可以将流量自动负载到后续 Pod 中,如果 Pod 提供的是 http 服务这个够用了,但如果是 grpc 这样的长链接,就需要使用 istio 这类服务网格,他可以识别出协议类型,从而做到请求级别的负载均衡。Operator
自动运维能力:k8s 可以根据应用的运行情况自动调整当前集群的 Pod 数量、存储等,拿 Pulsar
举例,当流量激增后自动新增 broker
,磁盘不足时自动扩容等。secret
可以保存一些敏感的配置或者文件。这个就是考察我们对 k8s
是否是熟悉了,常用的有:
这个问题我也觉得意义不大,只要写过 yaml
就会知道了,metadata, kind, apiVersion
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: app
name: app
其实就是一个 k8s 的 命令行客户端。
deployment
,这应该是最常见的部署方式。service
: 可以将流量负载到 Pod 中。Ingress
: 如果需要从集群外访问 Pod 就得需要 Ingress
然后 配合域名访问。k get containers
这个命令这个问题主要是看对 Pod
的理解,因为在 k8s
中 Pod
就是最小的单位了,如果想要访问容器可以在 Pod 中访问。
我们可以加上 -c
参数进入具体的容器。
kubectl exec -it app -c istio-proxy
这个主要是看日常使用时有没有遇到什么坑了:
yaml
内容是否正确,这个确实很重要,一旦执行错了后果很严重,比如使用 helm 的时候最好岂容 dry-run
和 debug
,先看看生成的 yaml
是否是预期想要的。helm upgrade app --dry-run --debug
# 资源限制
resources:
limits:
cpu: 200m
memory: 200Mi
requests:
cpu: 100m
memory: 100Mi
参考来源:https://github.com/bregman-arie/devops-exercises/blob/master/topics/kubernetes/README.md#kubernetes-101
后续部分内容也有出视频版,强烈建议大家关注我的 B 站或者是视频号:
往期推荐
本文分享自 crossoverJie 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!