k8s编排最佳实践
https://www.cnblogs.com/ksir16/p/9083869.html编排文件技巧· 使用资源时指定最新稳定版的API version· 编排文件应该纳入版本控制,这样可以在必要的时候快速回滚,同样也有利于资源恢复和重建· 使用YAML格式而不是JSON格式,尽管两种格式的文件可以相互转换,但是YAML格式更易读· 使用单一的文件组织相关资源,单文件比多文件更好组织管...
·
https://www.cnblogs.com/ksir16/p/9083869.html
编排文件技巧
· 使用资源时指定最新稳定版的API version
· 编排文件应该纳入版本控制,这样可以在必要的时候快速回滚,同样也有利于资源恢复和重建
· 使用YAML格式而不是JSON格式,尽管两种格式的文件可以相互转换,但是YAML格式更易读
· 使用单一的文件组织相关资源,单文件比多文件更好组织管理,可以参考guestbook-all-in-one.yaml
· 很多kubectl命令可以作用于整个文件夹,比如kubectl create somedir,可以对somedir目录中所有的配置文件执行create指令
· 对资源的描述可以写到annotations中,便于自省
裸Pod
不受任何控制器(Deployment,ReplicaSets,Jobs)控制的Pod称之为裸Pod
· 尽量避免使用裸Pod,因为在发生节点错误的时候没有任何策略保证Pod的重调度,死掉就彻底死掉了。
· 相反,Deployment会启动相应的ReplicaSet来保证Pod的可用数量,同时有更新策略提供对Pod的更新比如Rolling Update。
· 有些特殊只需要执行一次的场景可用Job替代
Service
service优先创建,理解为2点:service在它所依赖的资源创建出来之前创建;service在访问它的资源创建之前创建。k8s创建容器的时候会在容器中写入当前存在的service地址的环境变量,比如有个名称为foo的service,所有k8s创建出来的容器中都会有如下的环境变量
FOO_SERVICE_HOST=<the host the Service is running on>
FOO_SERVICE_PORT=<the port the Service is running on>
如果代码中要访问Service,不要使用上述环境变量,最好使用Service的dns名称,上述环境变量只是为了解决有些老的系统无法使用DNS查找问题的临时方案
如非必要,不要给Pod指定hostPort,因为会限制Pod被调度的可能
如果只是想访问某个端口进行debug,可以使用apiserver proxy或kubectl port-forward
如果确实需要暴露某个Pod的端口到主机端口,建议使用Service中的NodePort
使用标签(labels)
· 定义和使用语义明确的标签。比如{ app: myapp, tier: frontend, phase: test, deployment: v3 },
Service可以通过Selector实现跨Deployment组织资源;Deployment可以通过标签实现无中断更新
· 巧用标签进行调试。因为k8s资源控制器和Service都是通过标签来组织和管理资源的。移除Pod上的标签会导致控制器和Service不再将该Pod列为自己的资源,不再会有流量分配到该Pod。此时控制器会创建新的Pod来代替被移除的Pod,这是一种“隔离调试”技术。
容器镜像
· 默认的 imagePullPolicy是IfNotPresent,kubelet只有在本地不存在的情况下才会去拉取镜像。如果想每次执行都拉取镜像可以指定策略:imagePullPolicy: Always
还有一种方法是指定:latesttag,也会每次都拉取镜像
生产环境避免使用这种方式
使用kubectl
· 使用kubectl apply -f <directory>或kubectl create -f <directory>,会匹配目录中的.yaml .yml .json 文件
· get/delete命令建议搭配使用标签选择器而不是资源名,参考label selectors和using labels effectively
· 使用kubectl run和kubectl expose命令快速创建Deployment和Service,参考Use a Service to Access an Application in a Cluster
更多推荐
已为社区贡献1条内容
所有评论(0)