k8s编排最佳实践

编排文件技巧

• 使用资源时指定最新稳定版的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