对于大流量场景下实时流式计算中，K8S管理容器弹性伸缩是否有好的方案？

其实不单纯是实时计算，目前很多大数据场景都有这样的问题。在很多企业都有过CDH上云的经历，从过往情况来看，有三个难点，一个是大数据组件的融合，其中包括了 gettyimages/docker-spark与big-data-europe的Hadoop、Hive、HBase，其中版本一定要适配。第二个是创建容器的顺序问题，开启的顺序差异将导致容器是否能正常启动，如果启动失败，一般rc也将自动重新创建容器，如果还不行则需要手动删除，rc会自动重构。第三个就是题主所说的大流量场景下的kubernetes的性能和物理机的网卡流量分配问题，下面针对第三点进行展开。
一般来说，针对大流量的场景，一般采用利用亲和性和反亲和性，做pod 定点。 比如主流量入口，会有大量的流量进来，那么如果固定在node 节点上，那么根据 kubernetes调度pod 规则，会把这个大流量的pod 漂移到其他node节点上，但是问题很容易，影响这个node节点上的其他pod 容器的网络通信。举个现实遇到的案例， 有个服务主入口，那么这个容器只能固定在4个，4核16g 的高性能node 节点上，这样，因为网卡最多就是100m，那么即使是跑满了，也不会影响其他节点上的pod。简单说一下步骤，先 获取某个节点的labels， 修改labels 在命令行最后加上 --overwrite， 编辑app应用的deployment文件，利用筛选器字段，将容器固定制定的node节点，就可以实现 这个容器已经被k8s 调度到制定的节点上。