最近、オープンソースAPI管理プラットフォーム香港のサービス提供者は、最近、新しいオープンソースプロジェクトクマをリリースしました。この資料では、より良いくまプロジェクトを理解するために、くまグリッド・アプリケーションの展開をのBookInfoしようとします。
くまは、共通の制御プラットフォームは、第一世代ネットワークの技術的な制限を解決するために、シームレスなネットワークトラフィック管理層4-7、マイクロサービスとAPIを介してネットワークサービス（サービスメッシュ）を管理するために使用することができます。
クマは、その強調使いやすさを基礎となるネットワークの安全性と可観測性を確保するために、それは、高度なシンプルな制御インタフェースを提供した場合でも、しかし、ユーザーは、より高度な設定を行うことができます。くまの迅速なデータ収集プラットフォームと高度な制御プラットフォーム、簡単なコマンドを使用して、ユーザーは、あなたがアクセス権、オープンな指標を設定し、ルーティングルールを設定することができますことができます。
また、クマのソフトウェア定義のセキュリティは、ユーザーが指標を分析することができ、すべてのレイヤ4トラフィックに対してMTLSを有効にして、トラフィック制御、高精細、強化されたレイヤ4ルーティング機能を提供しますが、クマはすぐに追跡とロギング機能を実現することができますエラー調査。組織全体がネイティブクラウドアプリケーションを練習できるように、クマは、Kubernetes、仮想マシン、コンテナ、ベアメタル、伝統的な環境を含む、任意のプラットフォーム上で実行することができます。
オープンソースプロジェクト特使のくまの使用が開発された、と特使は、公式には注意し、特使は、サービスネットワークと一緒に、あるため、重要な実現ネイティブクラウドシステムとなっており、すでに政府機関の標準のエッジであるネイティブクラウドアプリケーションプロキシのために設計されています大規模なマイクロサービスアプリケーション、監視、セキュリティ、および信頼性のためのすべてのより重要です。
-
この記事のコードを使用してはGitHubの時（https://github.com/waret/kuma-tutorial）を見つけることができます。
まず、コントロールプレーンを設定するには、次のコマンドを使用し、ここでは、制御プレーンでのBookInfoという名前の新しいメッシュの作成です。
下图为 Bookinfo 应用的架构图，其中包含 productpage、reviews、details、ratings 等4个服务，另外 reviews 服务提供了三个版本。在这次测试中，我们为每个版本部署一个实例。
在数据平面，为了能在一个服务器中部署所有6个实例，这里为了避免冲突，需要考虑为各个实例合理分配 inbound 和 outbound 的端口，如下所示。
需要注意的一点，kuma-v0.1.2 版本中不支持在同一宿主机上部署多个 Sidecar，但是最新的 master 分支上已经做了修改，因此本文后面使用的 kuma 相关命令行程序都是从 master 分支全新编译出来的。
执行如下命令配置 ratings-v1 服务。
执行如下命令配置 details-v1 服务。
这里对 Istio 项目中的 bookinfo 代码进行了修改，以支持配置 RATINGS_PORT 参数，包括下面的 productpage 服务。执行如下命令配置 reviews-v1 服务。
执行如下命令配置 reviews-v2 服务。
执行如下命令配置 reviews-v3 服务。
执行如下命令配置 productpage-v1 服务。
打开浏览器，输入 http://$IP:10501/productpage，可以看到如下结果，也即bookinfo应用发布成功。刷新页面，可以看到review评分的变化。
为了测试数据平面可以动态更新配置，如下更新 bookinfo/reviews 服务的本地端口，并执行。
查看对应数据平面服务的日志，可以看到新的配置更新生效。但是这里的问题在于 productpage 实例本身仍然访问的是之前的 10504 端口，而 Sidecar 此时已无法实现该端口的转发，会导致服务本身的异常。所以总的来说，在 Kuma 的 Universal 模式下，一种比较好的实践是事先做好应用、服务、实例、端口等的规划，升级更新会导致服务的短暂中断。
总结
Kuma 的优势
-
轻量、轻量、轻量，重要的事情说三遍，几个可执行程序就能很方面的部署服务网格基础架构；
-
通过显而易见的方式支持多个Mesh，提供比较好的隔离性。
未解决的问题
-
不支持TrafficRoute、TrafficTracing等重要的功能，所以基本上Kuma还处于不可用状态。
-
双向认证只支持内建的自签名证书，且只能是在Mesh范围内进行配置。
-
由于不支持类似Istio中的Ingress、Egress等功能，当开启双向认证时，无法将服务对外发布出去，内部服务也无法访问外部的服务。
-
为了支持在Universal模式下同时启动多个Envoy，不支持Envoy的热重启。不过，由于xDS配置都是热更新，所以影响并不大。
-
在Universal模式下，不支持服务注册和发现，用户需要逐个为服务配置依赖应用的outbound入口，而且由于没有集成DNS，服务间访问需要指定到IP:Port，而不是像Istio一样指定Service Name即可。在Kubernetes模式下，则是依赖了Service的机制，可以将Hostname或Service Name解析为ClusterIP，随后发起的HTTP/TCP请求进入到Sidecar中以后再进行转发。
-
服务启动的过程中尽量不要访问依赖的服务，此时可能由于Sidecar及数据平面未配置好，导致服务启动失败。
-
查看Envoy的config_dump可以看到，当前都是以TCP连接的模式进行管理，完全没有发挥出Envoy的强大能力。
-
Universal模式下配置数据平面对象、启动Sidecar服务等方式都是需要管理员手工命令操作，更方便和人性化的包装也是必须的。
经过这次测试，我们可以看到 Kuma 当前还处于项目的初始阶段，但总的来说技术方向还是不错的。它不像 Istio 一下子就上一套大而全的功能，学习曲线来说比较平缓，可以让大家很好的理解服务网格技术能给大家带来的便利，以及其中存在的技术难点。
当前阻碍服务网格技术应用的原因之一是对历史遗留系统的支持。通常来说，我们需要对老的系统经过两次改造，第一次是容器化，使之能够运行在Kubernetes上，第二次则是对RPC框架的拆解或完全替换。
如果服务网格能够支持非容器场景，则至少工作还能减少一半。我们知道Istio在从v1.3版本开始，开始支持网格扩展，也即将虚拟机或裸金属主机集成到部署在Kubernetes中的Isito集群中。当前支持两种方式，一种是单网络方式，也即虚拟机或裸金属主机通过VPN或VPC连接至Kubernetes内部，另外一种是多网络下通过入口网关实现通讯集成。目前来看，由于Istio本身对Kubernetes的依赖比较重，再加上Istio本身的其它功能都已经相对比较完善，要想增加网格扩展的功能，工作量是比较大的，所以这两种方式都还处于开发状态。
相对来说，Kuma则提供了一种在虚拟机或裸金属主机场景下使用服务网格的新思路，虽然当前功能完成度相对太低，不过还是值得大家持续关注。