摘要：首先是要闻——Alluxio现在支持K8s Helm charts啦！K8s是Alluxio的一种经过认证的运行环境了。现在，重点是——Alluxio为K8s中的解耦式的数据分析技术栈带回了数据本地性。怎么做到的？继续读下去吧：）
在过去几年中，容器在实际部署中的兴起是毫无争议的。容器使得在任意环境中运行应用变得简单，而Kubernetes进一步改变了软件和应用程序的部署及扩展方式，而不用关心具体的环境。实际上，Kubernetes越来越被视为一项关键技术，它不仅让数据中心中的资源编排变得简单，并且在混合环境和多云环境中也是如此。尽管容器和Kubernetes在无状态应用程序（例如Web服务器）甚至完全独立的数据库（例如mongoDB，Couchbase等）上都表现出色，但在高级数据分析和AI的世界中，技术体系看起来有些不同。
现代的数据分析技术栈采用的是高度解耦的架构。与传统的数据库或数据仓库不同的是，新式的技术栈是分开的。
选择一个数据湖（或者两个、三个）用来存储数据（S3, GCS, HDFS等）选择一个计算框架用来分析数据（Apache Spark,Presto, Hive, TensorFlow等）确保其他所有的依赖项（如目录服务）均可用（Hive Metastore，AWS Glue，KMS等）在K8s中运行解耦数据分析栈的挑战
Kubernetes极大地降低了将多个分布式系统一起部署的复杂性。并且，在K8s集群上运行高级数据分析将成为常态。但是，要使这种现代的分析技术栈有效，仍然存在一些关键的差距需要弥补。
挑战#1——K8s集群中没有共享的数据访问/缓存层
K8s是一种出色的容器编排技术，借助Helm图表、算子等工具，可以大大简化部署。但是，对于诸如高级分析之类的数据密集型工作负载，我们通常需要有效地共享作业之间的数据，这样一个job中的数据才能被下一个job轻松地访问到。如果没有数据访问/缓存层，那我们就需要将数据写回到数据湖，然后又需要读回到K8s集群，这大大降低了数据流水线的效率。
挑战#2——缺少数据本地性
由于数据被存储在S3中，或其他云对象存储中，或Hadoop的本地存储中，为了在K8s集群中执行分析任务，用户只有两种选择。数据要么被远程访问（意味着性能不佳），要么被手动复制到K8s集群中（意味着每个工作负载的承担者会面临大量额外的DevOps和管理开销）。通常，管理这些副本之间的差异将带来沉重的负担。理想的解决方案是，在这种解构式的技术栈之中重新创造出数据局部性。
挑战#3——没有可用于弹性计算的数据弹性
K8s的优点在于，即使在最复杂的计算工作负载上，它也可以根据需要和需求灵活地扩展：缩小、升级、重新启动等。但是，对于数据密集型的工作负载而言，对于可获取的数据的依赖性依然存在。在对计算进行横向、纵向或者扩大、缩小的扩展时，K8s中的数据也必须能够完成同样的操作，这样才能利用K8s所带来的灵活性。
数据编排可以通过将数据同步到K8s集群中，并允许无缝的内存数据访问和灵活的跨作业数据共享，以及根据需要进行缩小或扩展，来解决这些挑战。
最新消息
Alluxio拥有自己的docker容器已经有一段时间了，但是随着Alluxio 2.1版本的发布，因为进行了K8s的高级测试和认证，Kubernetes成为了Alluxio的首选环境。我们现在正看到越来越多的生成环境将Alluxio以及Presto和Spark等计算框架一起部署在K8s中。
此外，Alluxio 2.1版本提供的一个新特性是支持Alluxio通过Helm Charts进行部署。
Helm Charts是什么？
Helm帮助您管理Kubernetes应用程序——Helm Charts能帮助您对即使是最复杂的Kubernetes应用程序进行定义，安装和升级。Charts的创建、版本控制、共享和发布都很容易——所以，开始使用Helm并停止“复制粘贴”吧。在此处了解更多信息：https://helm.sh
上手指南
要了解更多关于如何用Helm Charts部署Alluxio，可阅读相关文档（见参考链接1）。
您可以通过我们的docker sandbox教程（见参考链接2）来上手使用Alluxio！
参考链接：
链接1：https://docs.alluxio.io/ee/user/stable/en/deploy/Running-Alluxio-On-Kubernetes.html#deploy-using-helm
链接2：https://www.alluxio.io/products/aws/alluxio-presto-sandbox-aws/