常见问题

常见问题

TSB 和 Istio 的分别是什么?+

TSB 骨子里是使用 Istio 的,但披上了额外的功能,像是中央化管理、多用户、审查记录、工作流程、全网可用的服务资源库、详尽的生命周期管理,还有配置保护。

TSB 是由世界上的顶尖 Istio 专家打造和支持的。 我们坚信,透过向你的平台团队和应用团队提供量身订造的训练,还有了解你的架构和网格目标,而且计划如何合作达至目标,就能够帮助你建立起属于你机构内的网格专业团队。 当然,我们还会提供一周 7 天,一天 24 小时的全天候企业级支持,随时随地为你解决问题。

TSB 是不是开源的?+

Tetrate Service Bridge 本体是有专利的,可是它运用了行内最好的开源元件。 我们的团队包括 Istio、Envoy、Zipkin 和 Apache SkyWalking 的创始人和核心维护人员,这些项目合起来正好构成 Tetrate Service Bridge 的心脏。 我们也是 GetIstioGetEnvoy 的创始人。. 这些开源项目正是由 Tetrate 的人才精雕细刻,并运用在我们自家的产品上。

TSB 支持非 Kubernetes 的负载吗?+

支持。我们支持在虚拟机器和裸机上的起动服务。 在过程中,你会在虚拟机器和裸机的服务上运行 Sidecar, 它会扮演一个代理的角色,使得你的非 Kubernetes 服务能够参与到网格中。

Tetrate Service Bridge 可以在云端上运行吗? 在本地呢?+

可以。 TSB 本身就能够部署在公共云、私人云或者是本地上, 它也能在公共、私人、混合云,以及本地上,管理你的服务。

你们支持多重云的部署吗?+

支持。 TSB 可以同时地管理在一个集群中、或是多个集群之间的应用联网,除了集群,也可以是多重云、私人云,还有本地。

我的服务网格为什么需要多用户? +

TSB 的多用户是为了将问题区隔开,而且将管理资源独立起来,使得一个机构里的不同团队能够有各自的透明度和控制,而不会在工作上误触对方的区域。

安全性、网络、基础施设,以及应用问题,传统上是只分隔给所负责的团队。 所以在这种传统作业方式下,要在不同团队之间获得透明度和控制,就变得困难,也拖慢了业务的连续性和敏捷。

TSB 提供了一个协作的中心点,让所有持份者获得他们所需的控制,也写出他们所需透明度的政策,保证政策正确落实。

骨子底下,TSB 运用了网格原始的分隔功能,再按你的人员和资产的组织情况,加上合适的多用户模型和多个控制。 团队可以随意按他们工作内容和责任去组成。 服务也可以包装为逻辑应用,使得应用团队可以专注在他们需要监控以及管理的服务上。

向信息安全团队提供跨越多个用户和工作空间的控制,建立全网的默认政策 - 比如是默认拒线网络输出。

向应用团队提供自定义的查看权限,查看他们应用中服务。 而且,以往需要花上数天,甚至数周的时间,去跟信息安全团队和网络团队协调政策更新,现在只要在他们应用的范围中,赋予加减例外情况的自由-比例是允许某个服务的输出。

平台管理员对所有资源则有鸟瞰的权限,能够按各团队的需要组织他们。

在像 Kubernetes 的一个动态计算环境中,我该如何挡掉未经授权访问?+

TSB 将你的企业目录服务自动同步给每一位线上、线下的团队与成员。 如此一来,信息安全团队就可以透过 TSB 为业务相应的团队与成员定义角色和访问政策, 然后 TSB 会将那些角色和政策转移到你的下层基础设施,使得你不需要再直接在基础设施中直接配置。 换句话说,比如你不需要再在每一个 K8s 的集群中,配置团队和个人的访问权,还要保持更新。 Tetrate Service Bridge 按照你机构的目录服务,中央化编写政策,等于将你的这些事情全盘在握。

此外,中央化的政策会动态认证和动态授权每个负载的访问; mTLS 防止了窃听,确保信息层级的真实性与可信度; 还有, TSB 的多用户特色使得编写政策更容易,实现了将资源在需要允许给团队访问,而在不需要时保护起来。

 

该怎么将 mTLS 实施到我整个基础设施当中,包括在 K8s 和虚拟机器之间?+

TSB 实现了灵活的 mTLS,可以存在于任何线上负载和它的服务库之间,包括不论是多重集群、云和信息中心之间,还有在各种容器协调器和虚拟机器中的负载之间。

TSB 会与我现有的公钥基础设施兼容吗?+

TSB 将会和你选择的公钥基础设施互相融合。 不论你是否正在使用云供应商内建的证书管理系统,像 Venafi 或者 Keyfactor 等第三方的公钥基础设施;或者你需要融合你现有的私人、自主管理的公钥基础设施,Tetrate Service Bridge 都可以帮你达成目的。

我该如何保证以及证明,我所有的部署都正在应用一个一致化的认证政策?+

有别于为各种语言建立和维护各个独立的认证库,而每个库都有不同程度的素质和应用支持;使用服务网格,就正好透过它的 Sidecar 代理,为每个服务和每个应用提供了一个共同、一致化的政策执行机制。 Tetrate Service Bridge 允许你中央化地编写政策,确保政策可以在所有地方配置和执行。 TSB 同时保证每个政策都会被执行并有审查记录作为证明,而这些事你都可以一目了然。

TSB 如何透明地将流量从我本地的自主管理基础设施,转移到公众云服务上?+

TSB 使用了 Envoy 作为 Sidecar 或独立入口,将流量在集群和网站之间转移。为达到此目的, TSB 促进了运行时间服务的发现,同时也提供了全网视点,可以查看实时、历史上经过你基础设施的流量。

TSB 如何优化本地性,并最小化出口?+

多亏 Envoy 内建、具本地性意识和本地优先化的负载平衡,再加上 TSB 对你拓扑的深度理解,尽可能保证流量有效率地流动,TSB 会尽量处在本地区域和有效区域,负责转移明显流量和故障切换,以实现高效能和灾难修复。

要是碰上异作运作,我该如何安全地退出我的微服务实施,并重返到虚拟机器实施?+

就像 TSB 能够控制多集群和网站之间的流量一样,只要发出了请求,TSB 还能用于控制同一个网站下的不同服务, 使得在新服务异常运作和不能使用时,故障恢复能快速和自动地还原到基本。

在基础设施中止服务时,我该如何向开发人员提供故障切换的工具,并建立 HA 应用,以将损害减到最小?+

TSB 会替你建立一个多个独立的故障域(叫 Silos),然后在这些 Silos 中管理应用联网、安全性、配置和可观察性。 然后这些 Silos 会向应用团队提供部署、故障切换时需要的工具,确保在下层基础设施中止服务时,也能保持业务的连续性。

TSB 如何帮我将服务网格保持更新,而不会导致中止服务?+

TSB 提供有 Istio 和 Envoy 部署版本的集群详情,让你对自己基础设施的运作情况的最新状态一目了然。 至于升级的话,TSB 会测试运转新版本,让你在操作上更有保障,也保证在全面发布升级时会更安全。

我该如何允许我的开发人员,利用网格原始功能去建立可靠的应用?+

TSB 让你在整个机构中设置合理的默认值,并允许你的开发人员在需要时,逐渐消耗网格的功能性,同时又忽略掉过程当中的复杂性。

安排演示

资源

白皮书
Service Bridge - 连接旧有和现代设施的一道桥梁
Envoy 是自主服务、多租户的平台,在每台虚拟机器和 Kubernetes 集群相互之间,不管是本地部署或者在云端上,都连接并管理起来。

下载 ›

视频

开始投入使用
服务网格
Envoy 创始人 Matt Klein(Lyft 来福车)建议机构开始使用服务网格,逐步开始改变,一点一点解决问题。

马上观看 ›

个案研究

Istio 服务网格具备加密和 PCI 的合规
服务网格架构在控制和保障服务之间的通讯,提供了丰富的功能。 运送中的加密…

阅读更多 ›