fix broken links

pull/454/head
Jimmy Song 2021-10-20 18:01:57 +08:00
parent f3f3822615
commit 1252973b07
No known key found for this signature in database
GPG Key ID: CBA666E6EF8B2C3A
11 changed files with 31 additions and 190 deletions

View File

@ -33,10 +33,6 @@ Kubernetes 社区的贡献、交流和治理方式相关的内容都保存在 <h
- [opsnull/follow-me-install-kubernetes-cluster](https://github.com/opsnull/follow-me-install-kubernetes-cluster)
- [rootsongjc/kubernetes-handbook](https://github.com/rootsongjc/kubernetes-handbook)
## 幻灯片、图书和情报资料分享
- [cloud-native-slides-share](https://github.com/rootsongjc/cloud-native-slides-share) - Cloud Native 相关meetup、会议PPT、图书资料分享
## 博客与网站
Kubernetes和Cloud Native相关网站、专栏、博客等。
@ -73,12 +69,11 @@ Kubernetes和Cloud Native相关网站、专栏、博客等。
- [kubernetes](http://blog.kubernetes.io/)
- [moby](https://blog.mobyproject.org/)
- [openshift](https://blog.openshift.com/tag/kubernetes/)
- [pivotal](https://content.pivotal.io/)
- [platform9](https://platform9.com/blog/)
- [prometheus](https://prometheus.io/blog/)
- [rancher](https://rancher.com/blog/)
- [sysdig](https://sysdig.com/blog/)
- [spinnaker](https://blog.spinnaker.io)
- [twistlock](https://www.twistlock.com/blog/)
- [tetrate](https://tetrate.io/blog/)
- [vamp](https://medium.com/vamp-io)
- [weave](https://www.weave.works/blog/)

View File

@ -1,6 +1,6 @@
# 云原生应用之路——从 Kubernetes 到云原生
《从 Kubernetes 到云原生—— 云原生应用之路》,这是我最近在 [ArchSummit 2017 北京站](http://bj2017.archsummit.com/presentation/306) 和 [数人云 & TalkingData 合办的 Service Mesh is coming meetup](https://www.kubernetes.org.cn/3211.html) 中分享的话题。
注:本文根据笔者在 [ArchSummit 2017 北京站](http://bj2017.archsummit.com/presentation/306) 和 [数人云 & TalkingData 合办的 Service Mesh is coming meetup](https://www.kubernetes.org.cn/3211.html) 中分享的话题《从 Kubernetes 到云原生—— 云原生应用之路》改写而成
本文简要介绍了容器技术发展的路径,为何 Kubernetes 的出现是容器技术发展到这一步的必然选择,而为何 Kubernetes 又将成为云原生应用的基石。
@ -119,7 +119,7 @@ CNCF云原生计算基金会给出了云原生应用的三大特征
**迁移到云架构**
迁移到云端架构,相对单体架构来说会带来很多挑战。比如自动的持续集成与发布、服务监控的变革、服务暴露、权限的管控等。这些具体细节请参考 [Kubernetes Handbook](https://jimmysong.io/kubernetes-handbook) 中的说明,在此就不细节展开,另外推荐一本我翻译的由 Pivotal 出品的电子书——[《迁移到云原生应用架构》](https://content.pivotal.io/ebooks/migrating-to-cloud-native-application-architectures),推荐大家阅读。
迁移到云端架构,相对单体架构来说会带来很多挑战。比如自动的持续集成与发布、服务监控的变革、服务暴露、权限的管控等。这些具体细节请参考 [Kubernetes Handbook](https://jimmysong.io/kubernetes-handbook) 中的说明,在此就不细节展开,另外推荐一本我翻译的由 Pivotal 出品的电子书——[《迁移到云原生应用架构》](https://tanzu.vmware.com/content/ebooks/migrating-to-cloud-native-application-architectures),推荐大家阅读。
## 服务网格
@ -142,12 +142,11 @@ Kubernetes 中的应用将作为微服务运行,但是 Kubernetes 本身并没
- 扩展 kubernetes 的应用负载均衡机制,实现灰度发布
- 完全解耦于应用,应用可以无感知,加速应用的微服务和云原生转型
使用 Service Mesh 将可以有效的治理 Kubernetes 中运行的服务,当前开源的 Service Mesh 有:
使用 Service Mesh 将可以有效的治理 Kubernetes 中运行的服务,当前开源的流行的 Service Mesh 有:
- Linkderd[https://linkerd.io](https://linkerd.io/),由最早提出 Service Mesh 的公司 [Buoyant](https://buoyant.io/) 开源,创始人来自 Twitter
- Envoyhttps://www.envoyproxy.io/Lyft 开源的,可以在 Istio 中使用 Sidecar 模式运行
- Istio[https://istio.io](https://istio.io/),由 Google、IBM、Lyft 联合开发并开源
- Conduit[https://conduit.io](https://conduit.io/),同样由 Buoyant 开源的轻量级的基于 Kubernetes 的 Service Mesh
- [Linkerd](https://linkerd.io/):由最早提出 Service Mesh 的公司 [Buoyant](https://buoyant.io/) 开源,创始人来自 Twitter
- [Envoy](https://www.envoyproxy.io/):由 Lyft 开源,可以在 Istio 中使用 Sidecar 模式运行以作为数据平面,也可以基于它来构建自己的服务网格
- [Istio](https://istio.io):由 Google、IBM、Lyft 联合开发并开源
此外还有很多其它的 Service Mesh 鱼贯而出,请参考 [awesome-cloud-native](https://jimmysong.io/awesome-cloud-native)。
@ -155,12 +154,12 @@ Kubernetes 中的应用将作为微服务运行,但是 Kubernetes 本身并没
Linkerd 和 Istio 是最早开源的 Service Mesh它们都支持 Kubernetes下面是它们之间的一些特性对比。
| **Feature** | **Istio** | **Linkerd** |
| ----------- | ------------- | ---------------------------- |
| 部署架构 | Envoy/Sidecar | DaemonSets |
| 易用性 | 复杂 | 简单 |
| 支持平台 | Kubernetes | Kubernetes/Mesos/Istio/Local |
| 是否已有生产部署 | 否 | 是 |
| **Feature** | **Istio** | **Linkerd** |
| ---------------- | ------------- | ---------------------------- |
| 部署架构 | Envoy/Sidecar | DaemonSets |
| 易用性 | 复杂 | 简单 |
| 支持平台 | Kubernetes | Kubernetes/Mesos/Istio/Local |
| 是否已有生产部署 | 是 | 是 |
关于两者的架构可以参考各自的官方文档我只从其在Kubernetes上的部署结构来说明其区别。

View File

@ -211,7 +211,7 @@ Kubernetes 对象是 “目标性记录” —— 一旦创建对象Kubernete
* RBAC 授权
* kubelet TLS BootStrapping
* kubedns、dashboard、heapster\(influxdb、grafana\)、EFK\(elasticsearch、fluentd、kibana\) 集群插件
* 私有Docker镜像仓库[Harbor](https://github.com/vmware/harbor)请自行部署Harbor提供离线安装包直接使用docker-compose启动即可
* 私有Docker镜像仓库[Harbor](https://github.com/goharbor/harbor)请自行部署Harbor提供离线安装包直接使用docker-compose启动即可
**步骤介绍**
@ -298,7 +298,7 @@ Kubernetes是一个多租户的云平台因此必须对用户的权限加以
## 如何迁移到云原生应用架构
[Pivotal](https://pivotal.io/) 是云原生应用的提出者,并推出了 [Pivotal Cloud Foundry](https://pivotal.io/platform) 云原生应用平台和 [Spring](https://spring.io/) 开源 Java 开发框架,成为云原生应用架构中先驱者和探路者。
Pivotal后被 VMware 收购)是云原生应用的提出者,并推出了 [Pivotal Cloud Foundry](https://pivotal.io/platform) 云原生应用平台和 [Spring](https://spring.io/) 开源 Java 开发框架,成为云原生应用架构中先驱者和探路者。
原书作于2015年其中的示例主要针对 Java 应用,实际上也适用于任何应用类型,云原生应用架构适用于异构语言的程序开发,不仅仅是针对 Java 语言的程序开发。截止到本人翻译本书时,云原生应用生态系统已经初具规模,[CNCF](https://cncf.io/) 成员不断发展壮大,基于 Cloud Native 的创业公司不断涌现,[kubernetes](https://kubernetes.io/) 引领容器编排潮流,和 Service Mesh 技术(如 [Linkerd](https://linkerd.io/) 和 [Istio](https://istio.io/) 的出现Go 语言的兴起(参考另一本书 [Cloud Native Go](http://rootsongjc.github.io/cloud-native-go))等为我们将应用迁移到云原生架构的提供了更多的方案选择。
@ -473,7 +473,7 @@ Spark原生支持standalone、mesos和YARN资源调度现已支持Kubernetes
## 参考
* [迁移到云原生应用架构指南](https://jimmysong.io/migrating-to-cloud-native-application-architectures)
* [Cloud Native Go - 已由电子工业出版社出版](https://jimmysong.io/cloud-native-go)
* [Cloud Native Python - 已由电子工业出版社出版](https://jimmysong.io/posts/cloud-native-python)
* [Istio Service Mesh 中文文档 v1.2](https://archive.istio.io/v1.2/zh/)
* [迁移到云原生应用架构指南 - jimmysong.io](https://jimmysong.io/migrating-to-cloud-native-application-architectures)
* [Cloud Native Go - jimmysong.io](https://jimmysong.io/book/cloud-native-go/)
* [Cloud Native Python - jimmysong.io](https://jimmysong.io/book/cloud-native-python/)
* [Istio 官方文档(中文)- istio.io](https://istio.io/zh/)

View File

@ -79,138 +79,6 @@ OAM 模型中包含以下基本对象,以本文发稿时的最新 API 版本 `
- **转义层**:汇编好的文件将打包为 YAML 文件,由 Rudr 或其他 OAM 的实现将其转义为 Kubernetes 或其他云服务(例如 Istio上可运行的资源对象。
- **执行层**:执行经过转义好的云平台上的资源对象并执行资源配置。
## Rudr
> 注意Rudr 是对 [OAM v1alpha1](https://github.com/oam-dev/spec/releases/tag/v1.0.0-alpha.1) 在 Kubernetes 环境下的实现OAM 正在与 [Crossplane](https://github.com/crossplane/) 合作,不建议再使用 Rudr。
**Crossplane**
[Crossplane](./crossplane.md) 使用 Kubernetes 社区开创的以 API 为中心的声明式配置和自动化方法,使基础设施和应用管理标准化。官方网站:<https://crossplane.io/>
### 安装 Rudr
请参考 [Rudr 文档](https://github.com/oam-dev/rudr/blob/master/docs/setup/install.md)安装,主要依赖以下组件:
- kubectl
- helm 3
- Kubernetes 1.15+
执行下面的命令安装 Rudr 和需要的 trait。
```bash
# 克隆项目
git clone https://github.com/oam-dev/rudr.git
cd rudr
# 创建一个名为 oam 的 namespace
kubectl create namespace oam
# 安装 Rudr
helm install rudr ./charts/rudr --wait -n oam
# 要使用 ingress trait推荐安装 Nginx ingress
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
helm install nginx-ingress stable/nginx-ingress
# 要使用 autoscaler trait安装 HorizontalPodAutoscaler
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda -n oam
```
查看当前 oam namespace 下的所有 pod你会发现已创建了以下 pod。
```bash
$ kubectl get pod -n oam
NAME READY STATUS RESTARTS AGE
keda-operator-b6466c989-pn25n 1/1 Running 0 63m
keda-operator-metrics-apiserver-6cf88c468-k5wd8 1/1 Running 0 63m
nginx-ingress-controller-787bd69d8-n6v8c 1/1 Running 15 7d
nginx-ingress-default-backend-7c868597f4-vvddn 1/1 Running 2 7d
rudr-c648c9b7b-knj9b 1/1 Running 7 7d
```
## 部署示例
我们使用 OAM 官方提供的教程 [Tutorial: Deploy, inspect, and update a Rudr application and its components](https://github.com/oam-dev/rudr/blob/master/docs/tutorials/deploy_and_update.md) 中的 Python [flask](https://palletsprojects.com/p/flask/) 示例,该示例基于 OAM v1alpha1 API最新版 API 的示例可以参考 [crossplane-oam-sample](https://github.com/oam-dev/crossplane-oam-sample)。
```bash
# 部署 Component
kubectl apply -f examples/helloworld-python-component.yaml
```
此时 get pod 会发现并没有创建任何新的 pod因为 [examples/helloworld-python-component.yaml](https://github.com/oam-dev/rudr/blob/master/examples/helloworld-python-component.yaml) 文件中只定义了一个名为 `helloworld-python-v1``ComponentSchematic`,但是 `ComponentSchematic` 是仅仅是定义了一个组件而已,还无法直接创建 pod 的,还需要创建一个 `ApplicationConfiguration` 将其与 `Trait` 绑定才可以创建应用的 pod。
关于该示例的详细信息请参考 [Python flask 示例](https://github.com/oam-dev/rudr/blob/master/docs/how-to/create_component_from_scratch.md)的创建步骤。
### 创建应用配置
在部署了 `ComponentSchematic` 之后我们还需要创建一个 `ApplicationConfiguration` 将其与 `Trait` 资源绑定才可以创建应用。
**当前已有的 Trait**
在安装 Rudr 时已在 oam namespace 中部署了一些 trait使用下面的命令查看。
```bash
$ kubectl get trait -n oam
NAME AGE
auto-scaler 7d1h
empty 7d1h
ingress 7d1h
manual-scaler 7d1h
volume-mounter 7d1h
```
在 [examples/first-app-config.yaml](https://github.com/oam-dev/rudr/blob/master/examples/first-app-config.yaml) 中将 `ComponentSchematic` 与 ingress `Trait` 联系起来。一个完整的可部署的应用配置 [examples/first-app-config.yaml](https://github.com/oam-dev/rudr/blob/master/examples/first-app-config.yaml) 的内容如下所示:
```yaml
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
name: first-app
spec:
components:
- componentName: helloworld-python-v1 # 引用了上文中的 Component
instanceName: first-app-helloworld-python-v1
parameterValues:
- name: target
value: Rudr
- name: port
value: '9999'
traits:
- name: ingress # Ingress 引用Rudr 已默认创建
properties:
hostname: example.com
path: /
servicePort: 9999
```
执行下面的命令部署应用。
```bash
kubectl apply -f examples/first-app-config.yaml -n oam
```
若此时查看 oam namespace 下的 pod 将发现有一个新的 pod 创建。
```bash
$ kubectl get pod -o oam
NAME READY STATUS RESTARTS AGE
first-app-helloworld-python-v1-69945684c7-wfd82 1/1 Running 0 16m
...
```
### 测试
执行下面的命令可以测试刚安装的应用。
```bash
# 将 Python flask 应用的 pod 暴露到本机
export POD_NAME=$(kubectl get pods -l "oam.dev/instance-name=first-app-helloworld-python-v1,app.kubernetes.io/name=first-app" -o jsonpath="{.items[0].metadata.name}")
kubectl port-forward $POD_NAME 9999:9999
Forwarding from 127.0.0.1:9999 -> 9999
Forwarding from [::1]:9999 -> 9999
```
在浏览器中访问 <http://127.0.0.1:9999> 将看到 `Hello Rudr!` 的输出,这表示测试成功。
## 未来
从以上描述中可以看出 OAM 对于定义云原生应用标准的野望,其目标不仅限于 Kubernetes 之上的又一上层抽象而是对于一切云服务在基于资源对象的基础上Trait 来控制 Kubernetes 中的一众高层次非可调度的资源对象,如 AutoScaler、Volume、IngressIstio 中的流量配置对象 VirtualService、DestinationRule 等,还可容纳更多的云服务,对于 Serverless 时代的去基础设施化的思想不谋而合,未来可期。

View File

@ -152,10 +152,6 @@ Error from server (NotFound): Unable to list "crontabs": the server could not fi
如果稍后重新创建相同的 CustomResourceDefinition它将从空开始。
## 提供 CRD 的多个版本
有关提供 CustomResourceDefinition 的多个版本以及将对象从一个版本迁移到另一个版本的详细信息,请参阅[自定义资源定义版本控制](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/)。
## 高级主题
### Finalizer终结器

View File

@ -144,10 +144,6 @@ Kubernetes 然后查询新的自定义 metric API 来获取相应自定义 metri
## 参考
- HPA说明https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
- HPA详解https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
- 自定义metrics开发https://github.com/kubernetes/metrics
- 1.7版本的kubernetes中启用自定义HPA[Configure Kubernetes Autoscaling With Custom Metrics in Kubernetes 1.7 - Bitnami](https://docs.bitnami.com/kubernetes/how-to/configure-autoscaling-custom-metrics/)
- [HPA说明 - kubernetes.io(https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)
- [HPA详解 - kubernetes.io](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
- [自定义metrics开发 - github.com](https://github.com/kubernetes/metrics)

View File

@ -1,6 +1,6 @@
# Operator
Operator是由[CoreOS](https://coreos.com)开发的用来扩展Kubernetes API特定的应用程序控制器它用来创建、配置和管理复杂的有状态应用如数据库、缓存和监控系统。Operator基于Kubernetes的资源和控制器概念之上构建但同时又包含了应用程序特定的领域知识。创建Operator的关键是CRD自定义资源的设计。
Operator是由[CoreOS](https://coreos.com)开发的用来扩展Kubernetes API特定的应用程序控制器它用来创建、配置和管理复杂的有状态应用如数据库、缓存和监控系统。Operator基于Kubernetes的资源和控制器概念之上构建但同时又包含了应用程序特定的领域知识。创建Operator的关键是CRD自定义资源的设计。[awesome-operators](https://github.com/operator-framework/awesome-operators) 中罗列了目前已知的 Operator。
## 工作原理
@ -8,8 +8,6 @@ Operator是将运维人员对软件操作的知识给代码化同时利用Kub
Operator使用了Kubernetes的自定义资源扩展API机制如使用[CRD](../concepts/custom-resource.md)CustomResourceDefinition来创建。Operator通过这种机制来创建、配置和管理应用程序。
当前CoreOS依靠社区力量创建了众多的 Operator<https://operatorhub.io/>
Operator基于Kubernetes的以下两个概念构建
- 资源:对象的状态定义
@ -52,17 +50,10 @@ Operator本质上是与应用息息相关的因为这是特定领域的知识
6. Operator应该让用户能够根据版本声明来选择所需版本和编排应用程序升级。不升级软件是操作错误和安全问题的常见来源Operator可以帮助用户更加自信地解决这一问题。
7. Operator应该进行“Chaos Monkey”测试以模拟Pod、配置和网络故障的情况下的行为。
## OperatorHub
我们都知道在 Kubernetes 上安装应用可以使用 Helm 直接安装各种打包成 Chart 形式的 Kubernetes 应用,但随着 Kubernetes Operator 的流行Kubernetes 社区又推出了 [OperatorHub](https://www.operatorhub.io/),你可以在这里分享或安装 Operator<https://www.operatorhub.io>
另外,[awesome-operators](https://github.com/operator-framework/awesome-operators) 中罗列了目前已知的 Operator。
## 参考
- [Operators - coreos.com](https://coreos.com/operators)
- [awesome-operators - github.com](https://github.com/operator-framework/awesome-operators)
- [OperatorHub - operatorhub.io](https://www.operatorhub.io)
- [Writing a Kubernetes Operator in Golang](https://medium.com/@mtreacher/writing-a-kubernetes-operator-a9b86f19bfb9)
- [Introducing Operators: Putting Operational Knowledge into Software - coreos.com](https://coreos.com/blog/introducing-operators.html)
- [Automating Kubernetes Cluster Operations with Operators - thenewstack.io](https://thenewstack.io/automating-kubernetes-cluster-operations-operators/)

View File

@ -30,7 +30,7 @@
可以通过简单地从其service的选择器中省略特定于发行版本的标签而不是更新服务的选择器来完全匹配replication controller的选择器来实现跨越多个部署的服务例如滚动更新。
- 为了滚动升级的方便在Replication Controller的名字中包含版本信息例如作为名字的后缀。设置一个`version`标签页是很有用的。滚动更新创建一个新的controller而不是修改现有的controller。因此version含混不清的controller名字就可能带来问题。查看[Rolling Update Replication Controller](https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/)文档获取更多关于滚动升级命令的信息。
- 为了滚动升级的方便在Replication Controller的名字中包含版本信息例如作为名字的后缀。设置一个`version`标签页是很有用的。滚动更新创建一个新的controller而不是修改现有的controller。
注意 [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) 对象不需要再管理 replication controller 的版本名。Deployment 中描述了对象的期望状态如果对spec的更改被应用了话Deployment controller 会以控制的速率来更改实际状态到期望状态。Deployment目前是 [`extensions` API Group](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups)的一部分)。

View File

@ -35,7 +35,7 @@
+ RBAC 授权
+ kubelet TLS BootStrapping
+ kubedns、dashboard、heapster(influxdb、grafana)、EFK(elasticsearch、fluentd、kibana) 集群插件
+ 私有docker镜像仓库[harbor](https://github.com/vmware/harbor)请自行部署harbor提供离线安装包直接使用docker-compose启动即可
+ 私有docker镜像仓库[harbor](https://github.com/goharbor/harbor)请自行部署harbor提供离线安装包直接使用docker-compose启动即可
## 环境说明

View File

@ -5,4 +5,4 @@ mdspell --version
echo -ne "mdl "
mdl --version
htmlproofer --version
htmlproofer --url-ignore "/localhost/,/172.17.8.101/,/172.20.0.113/,/slideshare.net/,/grpc.io/,/kiali.io/,/condiut.io/,/twitter.com/,/facebook.com/,/medium.com/,/google.com/,/jimmysong.io/,/openfaas.com/,/linkerd.io/,/layer5.io/,/thenewstack.io/,/blog.envoyproxy.io/,/blog.openebs.io/,/k8smeetup.github.io/,/blog.heptio.com/,/apigee.com/,/speakerdeck.com/,/download.svcat.sh/,/blog.fabric8.io/,/blog.heptio.com/,/blog.containership.io/,/blog.mobyproject.org/,/blog.spinnaker.io/,/coscale.com/,/zh.wikipedia.org/,/labs.play-with-k8s.com/,/cilium.readthedocs.io/,/azure.microsoft.com/,/storageos.com/,/openid.net/,/prometheus.io/,/coreos.com/,/openwhisk.incubator.apache.org/,/dockone.io/,/jianshu.com/,/cloudstax.io/,/spring.io/" _book
htmlproofer --url-ignore "/localhost/,/servicemesher.com/,/172.17.8.101/,/172.20.0.113/,/slideshare.net/,/grpc.io/,/kiali.io/,/condiut.io/,/twitter.com/,/facebook.com/,/medium.com/,/google.com/,/jimmysong.io/,/openfaas.com/,/linkerd.io/,/layer5.io/,/thenewstack.io/,/blog.envoyproxy.io/,/blog.openebs.io/,/k8smeetup.github.io/,/blog.heptio.com/,/apigee.com/,/speakerdeck.com/,/download.svcat.sh/,/blog.fabric8.io/,/blog.heptio.com/,/blog.containership.io/,/blog.mobyproject.org/,/blog.spinnaker.io/,/coscale.com/,/zh.wikipedia.org/,/labs.play-with-k8s.com/,/cilium.readthedocs.io/,/azure.microsoft.com/,/storageos.com/,/openid.net/,/prometheus.io/,/coreos.com/,/openwhisk.incubator.apache.org/,/dockone.io/,/jianshu.com/,/cloudstax.io/,/spring.io/" _book

View File

@ -1,6 +1,6 @@
# Istio 如何支持虚拟机
> 本文基于 Istio 1.7 版本撰写。
注:本文基于 Istio 1.7 版本撰写。
Istio 是目前最流行的服务网格,用于连接、保护、控制和观察服务。当其 2017 年开源时Kubernetes 已赢得容器编排之战Istio 为了满足组织转向微服务的需求。虽然 Istio 声称支持异构环境,如 Nomad、Consul、Eureka、Cloud Foundry、Mesos 等,但实际上,它一直与 Kubernetes 合作得最好——它的服务发现就是基于 Kubernetes。
@ -49,17 +49,13 @@ Istio 社区和 [Tetrate](https://www.tetrate.io/) 在 Istio 对虚拟机的支
7. 将虚拟机中的 MySQL 服务作为 ServiceEntry 引入到 Mesh 中并作为 rating 服务的后端;
8. 修改 MySQL 表中的数据,验证 bookinfo 中的 rating 相应的行为符合预期;
点击下图[查看 Demo 视频](https://www.bilibili.com/video/bv1Wp4y167QT)。
[![Istio 支持虚拟机 Demo 视频](../images/istio-vm-demo-video.jpg)](https://www.bilibili.com/video/bv1Wp4y167QT)
## 未来方向
从 [bookinfo](https://istio.io/latest/docs/examples/virtual-machines/bookinfo/) 的演示中可以看出在这个过程中涉及到的人工工作太多很容易出错。在未来Istio 会改进虚拟机测试的可操作性,根据平台身份自动引导,改进 DNS 支持和 istioctl 调试等。大家可以关注 [Istio 环境工作组](https://github.com/istio/community/blob/master/WORKING-GROUPS.md),了解更多关于虚拟机支持的细节。
## 参考阅读
- [Virtual Machine Installation](https://istio.io/latest/docs/setup/install/virtual-machine/)
- [Virtual Machines in Single-Network Meshes](https://istio.io/latest/docs/examples/virtual-machines/single-network/)
- [Istio: Bringing VMs into the Mesh (with Cynthia Coan)](https://www.tetrate.io/blog/istio-bringing-vms-into-the-mesh-with-cynthia-coan/)
- [Bridging Traditional and Modern Workloads](https://www.tetrate.io/blog/bridging-traditional-and-modern-workloads/)
- [Virtual Machine Installation - istio.io](https://istio.io/latest/docs/setup/install/virtual-machine/)
- [Virtual Machines in Single-Network Meshes - istio.io](https://istio.io/latest/docs/examples/virtual-machines/single-network/)
- [Istio: Bringing VMs into the Mesh (with Cynthia Coan) - tetrate.io](https://www.tetrate.io/blog/istio-bringing-vms-into-the-mesh-with-cynthia-coan/)
- [Bridging Traditional and Modern Workloads - tetrate.io](https://www.tetrate.io/blog/bridging-traditional-and-modern-workloads/)