微服务架构系统中，程序的稳定运行的前提是需要保证每一个服务节点正产运行。此时，k8s容器技术就显得尤为重要了。
首先，k8s中有几大组件：
1，pod ：应用运行容器，我们的业务服务就在pod里运行
2，deployment： 容器管理组件，控制pod的运行。
3，svc：容器暴露方式：clusterIP,nodePort。指容器需要如何对外暴露
4，pv：PersistentVolume，文件存储服务，一般与nfs配合使用持久化存储于本地
5，pvc：PersistentVolumeClaim 文件存储申明服务，提供给存储应用使用如minio
6，ingress：服务集群的代理，通常使用域名绑定svc的方式把pod暴露给容器外访问。
通常一个服务的发布流程为:
引入自己的服务打包成docker镜像
>docker push 到镜像仓库
>书写deployment.yaml，在里面引入自己的镜像和启动参数
>运行kubectl create -f deployment.yaml
>创建svc暴露服务
通常在k8s自动部署的平台中，会借助2个工具来实现自动化部署：
1，git-runner
2，Dockerfile
2，helm chart
具体的流程如图：
当代码提交时，触发gitlab-ci.yml
>gitlab.ci中执行mvn clean package，
>docker build Dockerfile -t 打成镜像tag
>docker push 把镜像上传到镜像仓库
>最后执行chart_build
chart_build大概做了如下事情：
在values.yaml维护tag最新上传的镜像
>在chart中按需添加svc,ingress等信息
>通过values.yaml信息注入到deployment.yaml中，生成一个合法的deployment
>手动点击部署环境则会进行deployment,svc，ingress等组件的生成
k8s常用指令有如下：
查看组件:kubectl get （pod,svc,ingress,deployment,pv,pvc） -n namespace
查看pod的日志：kubectl logs -f podName -n namespace
查看deployment的配置：kubectl get deployment name -n namespace -o yaml
编辑deployment的配置：kubectl edit deployment name -n namespace -o yaml
进入pod:kubectl exec -it <runner pod> -n namespace bash
退出pod:exit
k8s ingress报错：413 Request Entity Too 解决方式：
在一级节点为metadata的二级节点annotations下添加：
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-body-size: 200m
如果是nginx直接配置，则添加：
client_max_body_size 200m;
