前言

嗯,人一偷懒就是大半个月的时间过去了。。。

被论文 还有那该死的复联三 折磨到变形,先丢个笔记上博客混个更新吧Orz


相关项目

  • containerd 项目(即将成为下一代默认容器运行时?)
  • LinuxKit 项目 VS Unikernel (前者进一步完成 Docker on Mac宿主操作系统封装的重要任务 )
  • CoreOS 公司(收购案)
  • Swarm项目(被Docker公司牺牲?)
  • VMware、Pivotal、Google Cloud合作推出的Pivotal Container Service(可以监控Kubernetes节点,意味着跨混合云和多云环境,利益相悖)

Docker公司

  • 当前专注于企业服务等更加现实的业务上
  • 开发者关系工作方面依然保持着强大的战斗力

k8s发展要点

落地障碍

graph LR
a(基础设施系统) --> b(工作层级低)
b --> c(强侵入性)

Kubernetes本身是基础设施领域的系统软件,这就意味着其工作层级低,而工作层级低在落地的过程中就会表现出强侵入性,意味着要接管用户的全套基础设施体系来发挥其“容器化”的核心能力

重点不在混合云

主要原因:利益相悖?

  • 确保用户只vendor lock在Kubernetes本身而不是某朵云的前提下,混合云的市场还是应该交给vendor

  • Kubernetes社区有多集群联邦管理能力推进相关项目(并非主旋律,被RedHat基于Kubernetes插件特性改造成了Multi-Cluster项目)

  • 随着 Kubernetes 项目和社区的进一步成熟,以及网络、存储和多租户特性的完善,多集群管理的优先级必然会在未来得到提升。

不会成为新一代PaaS

(更多是作者自己的看法,国内很多还是在提供Kubernetes+容器服务)

容器创业公司们关闭公有CaaS服务,转而专注于企业落地咨询业务

基于Kubernetes的PaaS(或者说CaaS)不足以拉开不同服务商之间差距

k8s项目不会成为一个新的PaaS,它的设计初衷不是直接在公有云上抢夺用户入口


容器生态焦点

玩家们

Azure

  • 明星业务: ACI(Serverless Container 服务)

  • 重点推广开源项目:

    • virtual-kubelet(ACI 的 Kubernetes 插件)
    • Brendan Burns 自己的 Metaparticle(Kubernetes 的 SDK)
  • 本质:围绕Azure本身的k8s服务构建起来的一系列Serverless业务

  • 最终目的:覆盖业务流程,对用户屏蔽学习曲线陡峭的k8s API

Google

  • GoogleContainerTools(GitHub Organization,Google Cloud 2018 年创建) 发布一系列k8s容器技术工具:
    • kaniko(镜像制作项目)
    • skaffold(持续集成项目)
    • Metacontroller(帮助用户快速编写符合 Kubernetes 编程范式的 API 插件的工具)
  • Google Cloud 基础设施团队
    • 开源了gVisor(基于用户态操作系统内核的容器项目),属于容器运行时安全这一新兴领域

Heptio

Kubernetes 集群运维全家桶:

  • 集群备份与恢复:Ark
  • 负载均衡:Contour
  • Ingress:Gimbal
  • 配置管理:Sonobuoy

最近转而专注于集群部署工作

CoreOS(RedHat收购)

在社区本就很具有影响力的 Operator Framework 计划(作业管理领域

基础上的二次创新

构建于 Kubernetes 之上的工具链:

  • Serverless Container Instance
  • Secure Container Runtime
  • ACI
  • Fargate
  • FaaS

其他等等

云平台的当前与未来

传统

先创建虚拟机,再创建容器,执行效率低

Serverless/虚拟化容器技术

KataContainers项目:

  • Intel ClearContainer + Hyper runV
  • 提供虚拟机的安全
  • 容器技术的迅速和易管理性
  • 目前托管于 OpenStack 基金会并接受 OCI 的指导
  • 代表目前 Kubernetes 社区最高优先级的特性之一:Secure Container Runtime
    • 无需虚拟机做宿主
  • 将来会以API的方式固化在Kubernetes项目中

未来

虚拟化容器:

  • 不同业务运行在不同的Guest Kernel上
  • Linux和Windows业务在同一宿主上混合部署

Google gVisor 和 Hyper linuxd 项目,会选择直接在用户态运行定制后的 Guest Kernel,从而在保证虚拟化级别的隔离能力的同时进一步降低 Sandbox 带来的性能损耗


Written with StackEdit.