12-Kubernetes运维最佳实践总结与CI和CD方案

[TOC]

0x00 前言简述

描述: 本章算是对前面Kubernetes学习的总结提炼以及最佳实践配置和K8s在持续集成、持续交互(CI/CD)中的应用方案。

学习了前面的几章我们发现Kubernetes的复杂性以及学习曲线都是比较陡峭的，而前面所学仅仅是一个基础打造，可以算是K8s真正入门和能搭建并且操作使用而已。所以在此之外我们也需进行不断的学习。

0x01 K8S 最佳实践

1.常规配置

• (1) 将K8s集群搭建或者应用配置文件纳入到版本控制当中，便于后期集群的重建恢复以及应用服务回滚。
• (2) 将构建、部署、测试与发布过程中相关的全部纳入到版本控制之中，包括但不限于应用代码、构建脚本、需求、设计、测试文档、代码库以及配置文件等等。
• (3) 将应用代码与应用配置进行隔离，根据不同的环境进行响应的配置，例如开发、预生产以及生产环境中同一个应用配置不尽相同(比如连接的后端数据库的不同)。

2.资源清单

• (1) 采用K8s部署应用时建议一组对象文件写一个单独文件(例如 Deployment 对象的yaml文件)，因为单个文件更方便进行管理。
• (2) 建议使用yaml格式而非JSON格式进行编写资源清单。
• (3) 建议使用当前最新且稳定版本的API来定义对象。
• (4) 建议把对象的描述信息写入到annotations中方便信息查找(例如在Kuboard 和 Nginx-Ingress 之中)。

3.Labels 配置

• (1) 针对于创建的资源应当使用有意义的标签方便后期调度和管理。例如: ｛app: nginx-demo, tier: frontend, env: production｝

4.Pod 配置

• (1) 建议不要创建一个裸Pod除非您是在测试容器，最好使用Deployment资源对象(也可以根据业务选择其它的资源对象)创建Pod，置于为什么我们在前面Controller讲解过。

5.Service 配置

• (1) 通常情况下Service创建应当在后端负载创建成功后(Deployment或者StatefulSet资源控制器管理的Pod)
• (2) 集群内部的服务发现建议使用k8s的DNS替代环境变量注入，便于先启动的Pod与后启动的Pod进行相互通信。
• (3) 建议避免使用hostPort和hostNetwork。

6.镜像容器

• (1) 根据业务需求设置imagePullPolicy其拉取策略默认为ifNotPreset, 如需每次获取到最新镜像则建议使用imagePullPolicy: Always;

7.代码配置分离

描述: 这是一个应用部署最佳的实践之一是代码和配置之间的分离，因为在一般情况下部署在不同环境下的代码都是相同的，唯一不同的是应用的配置。例如在开发环境、预生产环境以及生产环境同一个应用配置不尽相同。

所以自K8s 1.2开始支持一个被称为ConfigMap的API资源，采用ConfigMap可以实现应用与代码之间的分离，例如可以简单复习一哈ConfigMap的作用：

• 1) special-config ：英 [ˈspeʃl] 特殊的配置设置普通文本数据
• 2) env-config : 设置环境变量数据 (env 在对象消费)
• 3) file-config : 设置文件目录数据 (volumes 在对象消费)

8.简化配置方案

描述: 以下是正对于k8s的应用配置和部署简化的一些开源方案

• Helm (模板和配置推荐) 便于升级与回滚以及指定历史版本回滚。
• Kubecfg
• OpenShift
• Rancher
• Jenkins X