1. 基础功能
我们期望是实现一个尽可能自助的服务，所以里面先不考虑一些诸如审批，之类的操作，在此部分我们要完成应用从打包到上线的关键流程
1.1 镜像打包
研发编写好代码，此时就要进行代码的生产环境部署，而部署的最小单元通常就是Docker镜像，那么我们就要实现一个自助的镜像打包服务，来实现从源代码到docker镜像的交付
研发将代码提交到GIt代码仓库后，可以让代码仓库管理员设定一个回调钩子，通知我们的部署流水线，按照部署流水线按照之前设定的步骤来进行目标镜像的构建，并将构建的镜像发布到我们的镜像仓库中
其中部署流水线我们可以直接使用老牌的Jenkins，也可以选择Tekton这种云原生的部署工具
1.2 基础服务
如果仅仅从应用本身来说，除了基础的运行环境和代码，通常还会依赖于一些基础服务(不考虑应用层的依赖)， 比如mysql、redis、kafka等基础服务，但是诸如这种服务通常可能并不在k8s中(opeartor除外)，则此时我们就需要一种自助的集成方式，这里我们通过service catalog 进行集成，用户只需要进行申请，则就可以自助获取对应的基础服务资源
1.3 日志监控
应用上线后，我们如何获取到对应的健康状态呢？通常就需要日志和监控来进行辅助，我们希望一种方式可以自助的进行服务的日志收集、监控项的收集，此时我们就需要一种与监控和日志系统集成的方式， 还会涉及到各自监控告警，针对日志我们使用EFK来进行日志的收集，监控则采用Prometheus完成，此外除了应用的基础资源监控，可以让业务也进行对应业务指标的暴露，这样我们就可以实现业务层的指标级别的监控
1.4 负载均衡
应用上线后，通常需要对外提供访问，在k8s中因为网络的原因，通常需要通过ingress来进行网络内部service的暴露，则要给用户提供一个可以将服务和负载均衡自动关联的组件
负载均衡组件的选择通常有两种：老牌的负载均衡组件(Nginx/Kong/Haproxy)和微服务服务网关(Traefik)等，选择的核心通常是我们要不要改造，比如我们想在ingress上做一些基础验证、熔断、限流等实现则就需要进行二次开发，则就需要选择合适技术栈的ingress
这些Ingress通常我们需要一些专有节点，即只负责ingress的运行，即通常说的Proxy节点，我们需要结合K8s中的污点来进行一些控制，只允许ingress容器调度到这些节点上
1.5 部署更新
大多数应用都会随着产品的迭代或者bug修复，进行代码的迭代，而在k8s中则通常就是我们说的镜像更新，此过程可以借助k8s的deployment来进行自动完成
在应用更新的时候，通常需要进行灰度测试，即只允许部分用户进行访问，如果出现异常，则就立刻回滚，如果正常就滚动更新整个应用集群，而在k8s中实现该种方法主要包是通过Deployment来实现，我们这里主要是按照用户灰度的比例通过创建一个新的Deployment，如果成功就继续更新旧的Deployment来实现
1.6 应用下线
针对下线的应用，通常我们要进行对应的资源的释放操作，这里可能需要一个gc模块，负责应用的各种资源的清理工作
至此我们基于k8s和应用的一些基本需求，完成了基础版本的应用从代码打包、上线监控、部署更新、可观测性(日志监控)等基于云原生的应用全生命周期管理
