我和Datawire员工最近从巴塞罗那令人惊叹的KubeCon和CloudNativeCon会议中回来了。 我们参加了KubeCon的6场演出，在展位上分发了许多很酷的（没有虚假的谦虚）T恤，与数十人交谈并参加了很酷的表演。 在KubeCon EU上有很多有趣的事情，我决定写一篇重要成果的文章。
以下是我得出的结论（不按重要性排序）：
- 跨平台和混合云（仍然）很受欢迎。
- 技术集成正在蓬勃发展。
- 服务网格接口（SMI）公告：敬请期待。
- （朦胧？）Istio的未来。
- 随代码而行的政治。
- Cloud DevEx仍然不是没有问题。
- 公司（仍）处于技术采用的早期阶段。
- 本地Kubernetes是真实的（但很吸引人）。
- 考虑群集群。
- Kubernetes的成功仍然取决于社区。
会议上有几场有关多云（以及相关问题： 网络和安全性 ）的演讲 ，但我注意到最终用户报告中的许多介绍性幻灯片描述了至少有两个云提供商的基础架构或体系结构。 在Datawire展位上，我们比以前的会议更频繁地谈论多云过渡趋势。
Kubernetes的成功极大地简化了其多云战略，为交付和业务流程提供了出色的抽象。 在过去的两年中，Kubernetes的功能和API变得更加稳定，许多供应商都在使用该平台。 存储管理功能和网络连接已得到改善，并且在这一领域有足够好的开源商业产品和解决方案。 资深Google开发人员Saad Ali在他的演讲“揭穿神话：Kubernetes很难组织存储”中，以有趣的方式谈论了存储设施，Twistlock的Eran Yanay在“ Kubernetes中的连接：如何从头开始编写CNI插件 。 “
我特别喜欢有关将Azure与现有本地基础结构结合在一起的各种讨论。 我最近在InfoQ中写了一篇文章，内容涉及多平台体系结构与应用程序升级工作之间的关系。 我讨论了三种方法：在Azure Stack ， AWS Outposts和GCP Anthos中将云扩展到数据中心； 使用Kubernetes等平台确保多个供应商或云之间的供应结构（编排）的一致性; 使用API网关和服务网格（例如Ambassador和Consul ）确保服务（网络）结构的一致性。
Datawire的我们正在API网关上努力工作，并且显然正在倾向于一种灵活的第三种方法。 这使您能够从传统堆栈逐渐安全地迁移到更接近云的位置。 HashiCorp和Nick Jackson和我在KubeCon上发表了有关“确保从最终用户到服务的云连接”的演讲。
技术结合增长动力
许多供应商提供带有Kubernetes工具和其他技术的软件包。 我提请大家注意Rancher Labs发布的Rio MicroPaaS-最近他们一直在生产有趣的东西。 我在InfoQ中写了一篇有关Submariner的评论，该产品连接了多个集群和Kubernetes轻量级发行版k3s 。 而且我很想学习Supergiant的Kubernetes工具包 。 这是“用于自动化云中Kubernetes集群的供应和管理的一组实用程序”。
在公司环境中，程序包定向到存储。 一个很好的例子是VMware Velero 1.0 （基于从Heptio购买的开发 ），开发人员可以使用它保留和迁移Kubernetes资源和持久卷。
参加会议的还有许多其他在Kubernetes中存储和管理数据的运营商，例如CockroachDB ， ElasticCloud和StorageOS 。 来自Red Hat的Red Hat Rob Szumski谈到了Operator SDK和社区的发展，并介绍了Operator Hub 。 显然，操作员支持是Red Hat OpenShift企业套件的主要优点之一 。
服务网格接口（SMI）公告：敬请期待
微软的Gabe Monroy在一份报告中宣布了Service Mesh Interface（SMI） ， 无疑 引起了很大的反响 。 没有人会否认服务网格最近非常流行，SMI将把主要功能组合到一个标准接口中，并提供“一组通用的可移植API，这些API将确保不同服务网格技术（包括Istio，Linkerd和Consul Connect）之间的互操作性”。
在演示中， Gabe显示了主要功能：用于在服务之间应用凭据和传输加密等策略的流量策略（以Consul和Intent为例）； 流量监控-收集主要指标，例如服务之间交换数据时的错误数和延迟数（以Linkerd和SMI指标服务器为例）； 和流量管理-测量和转移不同服务之间的流量（例如，带有Weaveworks Flagger的Istio ）。
在这个竞争激烈的环境中定义一个接口会很有趣，但是我去了SMI网站 ，阅读了规范，并怀疑这种抽象可以简化为最小的一组通用功能（在我自己知道的解决方案中，这总是很难避免的） Java Community Process经验）。 潜在的危险是，尽管每个人都将应用此规范，但供应商将通过自定义扩展提供最有趣的功能。
我曾与Datawire的人员讨论过这一问题，我认为服务网格存在于一个市场上，即“赢者得到一切”的原则，因此最终，SMI将转移注意力，而另一种技术将简单地出现并收集所有收益（例如Kubernetes对Mesos，Docker Swarm等进行了处理。 跟踪新闻，看看会发生什么。
（朦胧？）Istio的未来
尽管关于服务网格的说法很多，但Istio的主题（也许是最著名的服务网格）却参差不齐。 有人认为，Istio和服务网格是同义词（如Docker和容器），并且只能看到解决方案，而不是问题。 有人喜欢Istio的功能； 有人对此技术并不特别满意。
最近 ，有关Istio基准测试的讨论很多，在1.1版中， 有意解决 了Mixer组件的一些问题。 有趣的是，我与对Istio进行了几个月评估的其他人进行了交谈（一个团队为此花费了将近一年的时间），他们声称Istio仍然非常复杂且占用大量资源。 有人说通过GKE发行托管Istio可以解决很多问题，但并不是每个人都可以使用GCP。
一位Google代表被问及Istio将会如何发展，是否会成为CNCF项目。 答案非常顺利，但含糊不清：Istio现在拥有开源代码，人们可以在上面进行开发，关于CNCF，请拭目以待。 到目前为止，尽管Envoy Proxy也是CNCF项目（而Istio，Ambassador API网关和许多其他技术都基于此），但只有Linkerd是CNCF中的官方服务网格项目。 在我们的展位上，许多人询问了Linkerd 2和Ambassador的集成 （感谢Buoyant技术总监Oliver Gould，他在Linkerd的详细评论中提到了Ambassador），与会人员喜欢Linkerd的易用性。
顺便说一句，当来自Knative的家伙在演讲“扩展Knative的乐趣和利润”中表示他们用Knative的大使代替Istio时，我感到很高兴，因为大使更易于使用（请注意照片中的T恤并在GitHub上阅读相应的任务： “将Istio删除为依赖项” ）：
随代码而行的政治
在我们的行业中，每个人都已经习惯于将政治作为与身份和访问管理系统（IAM），iptable配置，ACL和安全组关联的代码来呈现，但是到目前为止，这是在底层基础设施附近进行的。 当我听到Netflix的家伙在2017年在奥斯汀的KubeCon谈论使用开放策略代理（OPA）时 ，我想知道如何使用该项目将策略定义为代码。
在此KubeCon上，我看到随着代码的增加，政治问题越来越多，例如， 在Rita Zhang和Max Smythe的一次演讲中 ，越来越多的人讨论了OPA的使用，以及有关Kubernetes单元测试配置报告的更多内容。使用开放政策代理» Gareth Rushgrove（他对很有潜力的项目有天赋）。
我一直在遵循HashiCorp Sentinel在基础架构级别定义策略的方法，现在在Consul服务网格中使用Intention将这项技术推向更高的层次。 借助Intention，可以在服务级别定义策略。 例如，服务A可以与服务B进行通信，但不能与服务C进行通信。当Datawire团队开始与HashiCorp进行整合以整合大使和领事时，我们很快意识到将Intent与mTLS（用于识别服务）和ACL相结合的好处。 （以防止欺骗和多级保护）。
Cloud DevEx仍然无法做到
在闭幕词“不要停止相信”中 ，VMware的高级开发人员Bryan Liles谈到了开发人员工作流程的重要性（开发人员经验，DevEx），并且该话题已经多次讨论。 Kubernetes及其生态系统发展良好，但内部开发周期以及与Kubernetes的供应管道集成绝对需要改进。
克里斯蒂安·罗贾（Christian Roggia）在他的报告“ Bazel和网真中的可重现的开发和交付”中谈到了这一点。 他谈到了Engel和Volkers如何在其内部开发周期中使用CNCF Telepresence工具，以便他们在每次更改后都不必收集和运送容器。
与Weaveworks和Cloudbees的团队进行了有趣的小组讨论， “云中CI / CD的GitOps和最佳实践” ，详细讨论了持续交付。 GitOps的开发非常成功，因此在Datawire和会议中工作时，我经常遇到使用这种方法进行配置和交付的团队。 例如，乔纳森（Jonathan）和罗德里戈（Rodrigo）在其引人入胜的报告“与大使一起扩展Onefootball的边缘操作：每秒0到6,000个请求”中提到了这一点：
处于技术采用初期的公司（仍）
这是第一个KubeCon，在Datawire展位上，我与刚开始学习云技术的大公司的开发人员进行了很多交谈。 几乎每个人都听说过Kubernetes或尝试过Kubernetes，但是许多人仍在思考如何将其旧技术集成到新世界中。
CNCF生态系统主管谢丽尔·洪（Cheryl Hung）进行了多次讨论，包括“用云改造公司” ，很高兴听到Intuit等先驱的来信。 Laura Rehorst在她的演讲“从COBOL到Kubernetes：拥有250年历史的银行的云之旅”中，描述了荷兰银行如何应用计划和战略资源。
我们将Ambassador API网关放置在展位的正中央，因此经常有人问我们有关Kubernetes的现代网关与用于管理整个API生命周期的现有解决方案有何不同的问题。 现在，我们正在研究该领域的下一个商业产品- 大使代码 ，与开发人员讨论有关新云范例的要求和期望很有趣。
本地Kubernetes是真实的（但吸引人）
关于在本地安装Kubernetes的一些公告，特别是在公司环境中，例如， Kublr VMware与VMware和kubeadm的集成 。 红帽参加了有关OpenShift的所有讨论，而且我不止一次听到人们对OpenShift抽象的喜欢，而潜在的依赖性被改进的工作流程和SLA约定所抵消。
但是每个人都重复同样的事情：如果不是绝对必要的，则无需自己安装和维护Kubernetes。 即使您认为自己的公司很特别，也要花点时间：几乎所有可以使用公共云的公司都可以使用Kubernetes作为服务。
考虑集群群
在他的有趣的报告中， “ Spotify如何意外删除了所有Kube集群，而用户却没有注意到任何东西，” Spotify开发人员David Xia讲述了他们删除多个（！）工作集群时所学的知识。 我不会描述整个情况（观看视频），但是David的主要信息是将Kubernetes集群视为一个群体。 我想我们很多人都听过这句话：“像牛群一样对待服务器，而不是喜欢的宠物。” 但是David认为，随着计算抽象的发展（当我们将“数据中心视为计算机”时 ），我们应该应用相同的原理，而不必过于依赖我们的基础架构。
在他们的演讲中，Purvi Desai和Tim Hockin 共同开发了Kubernetes和GCP网络，邀请组织永久销毁，重新创建和迁移Kubernetes集群，以使其与它们无关。 主要论点是：如果不经常检查恢复群集和传输数据的能力，则在出现问题时可能不会成功。 想象一下，这是集群的混乱工程 。
Kubernetes的成功仍然取决于社区。
在报告中，包括午餐和整个过程中，关键主题之一是社区和多样性的重要性。 在星期四的早晨，LucasKäldström和Nikhita Raghunath在他们的报告“ Kubernetes社区的第一步”中不仅讲述了两个惊人的故事，而且还粉碎了那些不参与开源项目和CNCF项目的人的所有借口。 。
谢丽尔·洪（Cheryl Hung）在她的266万报告中，感谢她为该项目做出的巨大贡献，并为多样性和强大的领导力提供了有力的依据。 当我得知有300多种支持多样性的奖学金由CNCF内各组织的捐款资助时，我感到很惊讶。
KubeCon欧盟结论
再次感谢我们在巴塞罗那与之交谈的每个人。 如果您无法参加我们的演讲，请给我完整的清单：
在Datawire，我们遵循这些趋势，以确保Ambassador不断发展并满足云开发人员不断变化的需求。 如果您最近没有使用过Ambassador，请尝试使用我们的最新版本-具有内置Consul服务网格支持，自定义资源定义支持和许多其他功能的Ambassador 0.70 。
如果您在更新时遇到问题，请创建任务或在Slack中找到我们 。 如果您需要现成的具有集成身份验证，速度限制和支持的Ambassador安装，请尝试我们的商用Ambassador Pro产品。
如果您喜欢与大使合作，请告诉我们。 在文章下方发表评论或在Twitter上发布@getambassadorio 。