1
2
3
4
5
6
7
9
10
11
12
13
14
15
16
17
18
19
20
后期展望包括下面几个部分：
启动项管理，这个对应在启动上有先后顺序依赖的应用来说，是一个强诉求。目前docker compose 支持通过depends_on标签实现多个组件间启动顺序的管理。
k8s目前还不支持指定启动顺序的，只能通过init_container，在实例容器启动前对依赖的服务进行检测，检测到依赖的服务启动后再启动相应的容器。
2、应用下的日志聚合，其实这里应该还包括监控数据聚合。这个需求应该是系统基于服务组管理后的一个延展诉求，可以进一步强化服务组管理的能力。
3、调用关系展示，这个需求进一步在应用中突出服务与服务之间的依赖关系。更进一步对于调用链的追踪也是一个强诉求。
公共模板与应用市场，这个是应用编排更高阶的一个形式。通过应用市场可以快速的实现通用软件的容器化部署。
接下来是互动问答的内容：
Q: 应用下的服务展示（未部署），是yaml资源没有创建，还是副本数为0？
W: 未部署状态是yaml资源还没有创建
Q: 腾讯云能否将Kubernetes应用编排过程做成博客或视频的形式具体分享一下？
W: 我们接下来会将Kubernetes应用编排过程做成博客分享出来，后面也会做出视频分享给大家
Q: 腾讯云k8s网络用的是哪个组件呢？
W: 我们用的是全局路由的方式，直接和我们腾讯云容器服务的VPC网络打通。
Q: 使用configmap的时候，在配置修改完，需要重启服务。腾讯云容器服务配置文件的变更如何触发服务的重新启动？
W: 通过触发器的模式，可以在修改配置时触发服务的更新。
Q: 之前讲到可以结合CI/CD流程，通过CI编译生成新的镜像，修改配置项中镜像tag的参数，自动触发对应服务的更新。 这部分有详细例子吗？
W: 我们会将详细示例放到腾讯云容器服务帮助文档，在腾讯云分享论坛--腾云阁后面也可以看到。
Q: 应用配置如何实现版本控制的？
W: 对于每一个配置文件，我们支持每一次修改默认创建一个新的版本，具有唯一的版本号
Q：应用里的服务具体要怎么更新呢？
W: 一般建议的更新方法是，先修改配置，会生成配置的一个新的版本，这样这次修改在配置中是可以记录的。然后更新应用汇总配置文件的版本。触发或者手动更新对应的服务。
在修改配置文件的版本后，我们会比较出哪些服务有变化，需要更新。
Q：应用里的服务具体要怎么更新呢？
W: 一般建议的更新方法是，先修改配置，会生成配置的一个新的版本，这样这次修改在配置中是可以记录的。然后更新应用汇总配置文件的版本。触发或者手动更新对应的服务。
在修改配置文件的版本后，我们会比较出哪些服务有变化，需要更新。
Q: 外部访问集群是通过Nginx转发到pod还是通过k8s本来都dns服务来转发，两者优缺点是什么？
W: 外部访问，支持两种方式。
一种是通过服务的LB直接转发到对应的Pod，但需要在创建服务时指定访问方式为外部访问(对应于k8s中的LoadBanace方式)。
另外一种是通过ingress的方式。这种方式会有一个统一的LB作为入口。然后配置对应的后端域名转发规则。可以将外部的访问按照配置的规则转发后端的服务。
Q: 上面提到 应用模版+应用配置=应用实例，这样一个应用模版可以对应多个应用配置并生成多份应用实例吗？例如生成200个实例，如果可以如何写ci比较合适？
W: 这个是可以的，并且我们提供集群隔离和命名空间隔离。方便多个应用实例的创建。
Q: 应用的扩容缩容通过什么监控，有什么指标可以参考？
W: 自动扩容和缩容我们参考的是社区HPA的方案。指标目前考虑的是CPU和内存。
Q: 状态化的容器怎么做的？
W: 目前看到的有三种方式：一种是社区推荐的Stateful资源+headles service另外一种是：将服务的每一个实例拆分成独立的headless service
第三种是： 采用CoreOS提出的operater方式。存储部分一般推荐使用PVC的方式，但有其他的存储方式也可以。
