fix broken links
Jimmy Song
parent
f3f3822615
commit
1252973b07
|
|
@ -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/)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
- Envoy：https://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)。
|
||||
|
||||
|
|
@ -156,11 +155,11 @@ Kubernetes 中的应用将作为微服务运行，但是 Kubernetes 本身并没
|
|||
Linkerd 和 Istio 是最早开源的 Service Mesh，它们都支持 Kubernetes，下面是它们之间的一些特性对比。
|
||||
|
||||
| **Feature** | **Istio** | **Linkerd** |
|
||||
| ----------- | ------------- | ---------------------------- |
|
||||
| ---------------- | ------------- | ---------------------------- |
|
||||
| 部署架构 | Envoy/Sidecar | DaemonSets |
|
||||
| 易用性 | 复杂 | 简单 |
|
||||
| 支持平台 | Kubernetes | Kubernetes/Mesos/Istio/Local |
|
||||
| 是否已有生产部署 | 否 | 是 |
|
||||
| 是否已有生产部署 | 是 | 是 |
|
||||
|
||||
关于两者的架构可以参考各自的官方文档，我只从其在Kubernetes上的部署结构来说明其区别。
|
||||
|
||||
|
|
|
|||
|
|
@ -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/)
|
||||
|
|
|
|||
|
|
@ -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、Ingress，Istio 中的流量配置对象 VirtualService、DestinationRule 等，还可容纳更多的云服务，对于 Serverless 时代的去基础设施化的思想不谋而合，未来可期。
|
||||
|
|
|
|||
|
|
@ -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（终结器）
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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/)
|
||||
|
|
|
|||
|
|
@ -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)的一部分）。
|
||||
|
||||
|
|
|
|||
|
|
@ -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启动即可）
|
||||
|
||||
## 环境说明
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)。
|
||||
|
||||
[](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/)
|
||||
Loading…
Reference in New Issue