- SAP Managed Tags:
本文的目的是简要的描述一下什么是Kyma，主要内容译自 What is Kyma? | SAP Blogs，阅读时间约为10分钟。
个人理解上，Kyma的目的是通过预先选定的技术组件来搭建K8S，以降低常见的K8S部署/运维工作量，虽然说预选定的技术组件不那么灵活，但是至少给开发者提供了一个模板，开发者还可以根据自己的需要去替换组件（当然了，如果发现大部分组件都需要替换，这个时候Kyma就不太适用了）
根据最近完成的CNCF调查，云原生技术在生产中的Adoption正在快速增长。Kubernetes是这场技术革命的核心。当然，云原生科技的复杂性也在增加。只要在谷歌上搜索“Kubernetes很难”这句话，你就会得到很多解释这个复杂性问题的文章。开源社区最好的一点是，像这样的问题可以通过构建新的工具来解决，以支持Kubernetes用户：例如，Knative及其 Build resource扩展等项目可以降低一系列场景的复杂性。尽管增加复杂性似乎是最需要解决的问题，但这并不是过渡到云原生时面临的唯一挑战。
部署好Kubernetes不是结束，而是一个新的开始，云原生并不仅仅意味着开发。开发人员还需要搭配技术组件以实现存储、备份、监控、日志记录功能，还需要维护服务网格来令数据的传输符合要求。每一个技术组件都必须自行摸索。而CNCF提供了大量可用的技术组件。我们提供了所有云原生技术的概览（Cloud Native Landscape (cncf.io)），但列表非常庞大，可能加载页面都会需要一些时间。
该项目旨在为您提供编写端到端、生产级云原生应用程序所需的工具。Kyma已经由SAP：一家在编写生产级云原生应用程序方面经验丰富的公司捐赠给开源社区
试着在谷歌上搜索单体应用到云原生服务，或者从单体应用到微服务，你会得到大量应对这一挑战的演讲和论文。有许多不同的路径可用于将单体应用迁移到云，我们的经验教会我们在这一领域要有相当的主见。首先，让我们来回答为什么您希望从单体迁移到云原生的问题。推动这一举措的目标通常是：
而有了Kyma，只需使应用架构能够支持事件驱动即可，不必全部重写单体应用，就可以达成这些目标。
Kyma运行在Kubernetes上，由许多不同的组件组成，其中三个组件是：
Application connector，可用于将任何App与Kubernetes集群连接，并通过Kuberneteservice catalog公开其API和Event。
Serverless ，使您能够轻松地为App编写扩展。您的function code可以由API调用触发，也可以由来自外部系统的event触发。您还可以从您的function中安全地Call back集成系统。
Service Catalog ，在此集成系统。这种集成还使您能够使用Azure、AWS或谷歌云等IaaS服务。Kyma可以通过service brokers与微软和谷歌轻松集成。
只有对Kyma这样的项目进行适当的监控和配置，才能在该项目中提供可靠的可扩展性。我们决定不重新造轮子。CNCF基金会中有许多伟大的项目，大多数项目背后都有庞大的社区。我们决定挑选最好的，把它们组合在一起。您可以看到与上面相同的架构图，但重点是我们为创建Kyma而组合的项目：
您不必手动集成这些工具：我们确保它们都能很好地配合使用，并且始终是最新的（Kyma已经在使用Istio 1.1）。通过我们的自定义Installer(https://github.com/kyma-project/kyma/blob/master/docs/kyma/04-02-local-installation.md)和Helm图表，我们可以轻松安装和升级到Kyma的新版本。
重写很难，成本很高，而且在大多数情况下不需要重写。归根结底，你需要的是能够更快地编写新功能并将其投入生产。您可以使用Application Connector将您的单体应用连接到Kyma。简而言之，该组件确保：
目前，您的单体应用可以使用三种不同类型的服务：REST（具有OpenAPI规范）和OData（具有实体数据模型规范）用于同步通信，而对于异步通信，您可以基于AsyncAPI规范注册catalog of events。这些Event稍后将通过Knative Eventing使用NATS Streaming channel在内部传递。
一旦您的单体应用的服务被连接，您就可以在选定的命名空间使用它们，这要归功于前面提到的service catalog集成。作为开发人员，您可以访问目录并查看您可以使用的所有服务的列表。有来自您的单体应用的服务，还有来自其他第三方提供商的服务，这要归功于注册的服务经纪人，如Azure的OSBA。这是唯一一个拥有你所需要的一切的地方。如果你想建立一个新的应用程序，你需要的一切都已经在Kyma提供了。
查看将一个单体应用与Azure服务集成的一些代码。我想了解客户在产品评论部分的感受。在每一个有文字的评论中，我都想调用情绪分析服务来确保在出现负面评论的情况下将其存储在数据库中，以便稍后进行分析。这是由于我们的Serverless组件而创建的函数的代码。请注意我的代码注释：
多亏了Kyma，我不必担心我的应用功能周围的基础设施。我拥有Kyma所需的所有工具，它们集成在一起。我可以通过Loki快速访问我的日志，也可以快速访问预配置的Grafana仪表板，查看Prometheus和Istio提供的Lambda的指标。
关于本文内容有任何问题或见解，欢迎在评论区留下你的想法，如果需要帮助，也可以直接联系到我 arthuryang1996@foxmail.com，感谢你的时间
个人理解上，Kyma的目的是通过预先选定的技术组件来搭建K8S，以降低常见的K8S部署/运维工作量，虽然说预选定的技术组件不那么灵活，但是至少给开发者提供了一个模板，开发者还可以根据自己的需要去替换组件（当然了，如果发现大部分组件都需要替换，这个时候Kyma就不太适用了）
如果您对BTP感兴趣，BTP个人精选内容目录 | SAP Blogs 可能有更多你需要的内容
Kyma-轻松扩展和构建Kubernetes
根据最近完成的CNCF调查，云原生技术在生产中的Adoption正在快速增长。Kubernetes是这场技术革命的核心。当然，云原生科技的复杂性也在增加。只要在谷歌上搜索“Kubernetes很难”这句话，你就会得到很多解释这个复杂性问题的文章。开源社区最好的一点是，像这样的问题可以通过构建新的工具来解决，以支持Kubernetes用户：例如，Knative及其 Build resource扩展等项目可以降低一系列场景的复杂性。尽管增加复杂性似乎是最需要解决的问题，但这并不是过渡到云原生时面临的唯一挑战。
需要解决的问题
选择合适的技术很难
部署好Kubernetes不是结束，而是一个新的开始，云原生并不仅仅意味着开发。开发人员还需要搭配技术组件以实现存储、备份、监控、日志记录功能，还需要维护服务网格来令数据的传输符合要求。每一个技术组件都必须自行摸索。而CNCF提供了大量可用的技术组件。我们提供了所有云原生技术的概览（Cloud Native Landscape (cncf.io)），但列表非常庞大，可能加载页面都会需要一些时间。
该项目旨在为您提供编写端到端、生产级云原生应用程序所需的工具。Kyma已经由SAP：一家在编写生产级云原生应用程序方面经验丰富的公司捐赠给开源社区
很难决定从单一到云原生的路径
试着在谷歌上搜索单体应用到云原生服务，或者从单体应用到微服务，你会得到大量应对这一挑战的演讲和论文。有许多不同的路径可用于将单体应用迁移到云，我们的经验教会我们在这一领域要有相当的主见。首先，让我们来回答为什么您希望从单体迁移到云原生的问题。推动这一举措的目标通常是：
- 增强可扩展性。
- 更快地实现新功能。
- 更灵活的扩展方法。
而有了Kyma，只需使应用架构能够支持事件驱动即可，不必全部重写单体应用，就可以达成这些目标。
Kyma如何解决您的挑战？
Kyma是什么？
Kyma运行在Kubernetes上，由许多不同的组件组成，其中三个组件是：
Application connector，可用于将任何App与Kubernetes集群连接，并通过Kuberneteservice catalog公开其API和Event。
Serverless ，使您能够轻松地为App编写扩展。您的function code可以由API调用触发，也可以由来自外部系统的event触发。您还可以从您的function中安全地Call back集成系统。
Service Catalog ，在此集成系统。这种集成还使您能够使用Azure、AWS或谷歌云等IaaS服务。Kyma可以通过service brokers与微软和谷歌轻松集成。
我们为您选择了合适的技术
只有对Kyma这样的项目进行适当的监控和配置，才能在该项目中提供可靠的可扩展性。我们决定不重新造轮子。CNCF基金会中有许多伟大的项目，大多数项目背后都有庞大的社区。我们决定挑选最好的，把它们组合在一起。您可以看到与上面相同的架构图，但重点是我们为创建Kyma而组合的项目：
- 监测和警报基于Prometheus and Grafana
- 日志记录基于Loki
- Eventing使用Knative和NATS
- Asset management使用Minio作为存储
- Service Mesh基于Istio
- Tracing由Jaeger完成
- Dex负责支持身份验证
您不必手动集成这些工具：我们确保它们都能很好地配合使用，并且始终是最新的（Kyma已经在使用Istio 1.1）。通过我们的自定义Installer(https://github.com/kyma-project/kyma/blob/master/docs/kyma/04-02-local-installation.md)和Helm图表，我们可以轻松安装和升级到Kyma的新版本。
不要重写你的单体应用
重写很难，成本很高，而且在大多数情况下不需要重写。归根结底，你需要的是能够更快地编写新功能并将其投入生产。您可以使用Application Connector将您的单体应用连接到Kyma。简而言之，该组件确保：
- 您可以安全地回调已注册的单体应用，而无需担心授权，因为Application Connector会处理这一问题。
- 从您单体应用的Event 总线发送的Event可以安全地到达Kyma Event 总线。
目前，您的单体应用可以使用三种不同类型的服务：REST（具有OpenAPI规范）和OData（具有实体数据模型规范）用于同步通信，而对于异步通信，您可以基于AsyncAPI规范注册catalog of events。这些Event稍后将通过Knative Eventing使用NATS Streaming channel在内部传递。
一旦您的单体应用的服务被连接，您就可以在选定的命名空间使用它们，这要归功于前面提到的service catalog集成。作为开发人员，您可以访问目录并查看您可以使用的所有服务的列表。有来自您的单体应用的服务，还有来自其他第三方提供商的服务，这要归功于注册的服务经纪人，如Azure的OSBA。这是唯一一个拥有你所需要的一切的地方。如果你想建立一个新的应用程序，你需要的一切都已经在Kyma提供了。
最后是一些代码
查看将一个单体应用与Azure服务集成的一些代码。我想了解客户在产品评论部分的感受。在每一个有文字的评论中，我都想调用情绪分析服务来确保在出现负面评论的情况下将其存储在数据库中，以便稍后进行分析。这是由于我们的Serverless组件而创建的函数的代码。请注意我的代码注释：
多亏了Kyma，我不必担心我的应用功能周围的基础设施。我拥有Kyma所需的所有工具，它们集成在一起。我可以通过Loki快速访问我的日志，也可以快速访问预配置的Grafana仪表板，查看Prometheus和Istio提供的Lambda的指标。
关于本文内容有任何问题或见解，欢迎在评论区留下你的想法，如果需要帮助，也可以直接联系到我 arthuryang1996@foxmail.com，感谢你的时间
