Linus Lee
GitHub
commit
259458f375
|
|
@ -6,8 +6,9 @@
|
|||
|
||||
本书的主题不仅限于Kubernetes，还包括以下几大主题：
|
||||
|
||||
- 云原生开源组件
|
||||
- 云原生应用与微服务架构
|
||||
- 将微服务与Service Mesh架构
|
||||
- 基于Kubernete的Service Mesh架构
|
||||
- Kubernetes与微服务结合实践
|
||||
|
||||
起初写作本书时，安装的所有组件、所用示例和操作等皆基于**Kubernetes1.6+** 版本，同时我们也将密切关注kubernetes的版本更新，随着它的版本更新升级，本书中的Kubernetes版本和示例也将随之更新。
|
||||
|
|
@ -15,6 +16,10 @@
|
|||
- GitHub地址：https://github.com/rootsongjc/kubernetes-handbook
|
||||
- Gitbook在线浏览：https://jimmysong.io/kubernetes-handbook/
|
||||
|
||||
## 快速开始
|
||||
|
||||
如果您想要学习Kubernetes和云原生应用架构但是又不想自己从头开始搭建和配置一个集群，那么可以直接使用[**kubernetes-vagrant-centos-cluster**](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)项目直接在本地部署一个3节点的分布式集群及其他如Heapster、EFK、Istio等可选组件。
|
||||
|
||||
## 贡献与致谢
|
||||
|
||||
感谢大家对本书做出的贡献！
|
||||
|
|
|
|||
|
|
@ -196,7 +196,7 @@
|
|||
* [集成虚拟机](usecases/integrating-vms.md)
|
||||
* [Istio中sidecar的注入规范及示例](usecases/sidecar-spec-in-istio.md)
|
||||
* [如何参与Istio社区及注意事项](usecases/istio-community-tips.md)
|
||||
* [Istio 教程](usecases/istio-tutorial.md)
|
||||
* [Istio教程](usecases/istio-tutorial.md)
|
||||
* [Linkerd](usecases/linkerd.md)
|
||||
* [Linkerd 使用指南](usecases/linkerd-user-guide.md)
|
||||
* [Conduit](usecases/conduit.md)
|
||||
|
|
|
|||
|
|
@ -1,15 +1,17 @@
|
|||
# Kubernetes版本更新日志
|
||||
|
||||
刚开始写作本书时kubernetes1.6刚刚发布，随后kubernetes基本以每3个月发布一个版本的速度不断迭代，为了追踪不同版本的新特性，我们有必要在此记录一下。
|
||||
刚开始写作本书时Kubernetes1.6刚刚发布，随后Kubernetes基本以每3个月发布一个版本的速度不断迭代，为了追踪不同版本的新特性，我们有必要在此记录一下。
|
||||
|
||||
每个kubernetes版本的详细更新日志请参考：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md
|
||||
每个Kubernetes版本的详细更新日志请参考：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md
|
||||
|
||||
## 发布记录
|
||||
|
||||
- 2017年6月29日 [Kubernetes1.7发布](kubernetes-1.7-changelog.md)
|
||||
- 2017年9月28日 [Kubernetes1.8发布](kubernetes-1.8-changelog.md)
|
||||
- 2017年12月15日 [Kubernetes1.9发布](kubernetes-1.9-changelog.md)
|
||||
- 2017年6月29日，[Kubernetes1.7发布](kubernetes-1.7-changelog.md)
|
||||
- 2017年9月28日，[Kubernetes1.8发布](kubernetes-1.8-changelog.md)
|
||||
- 2017年12月15日，[Kubernetes1.9发布](kubernetes-1.9-changelog.md)
|
||||
- 2018年3月26日，[Kubernetes1.10发布](kubernetes-1.10-changelog.md)
|
||||
- 2018年6月27日，[Kubernetes1.11发布](kubernetes-1.11-changelog.md)
|
||||
|
||||
## 更多
|
||||
|
||||
追踪 Kubernetes 最新特性，请访问互动教学网站提供商 [Katacoda.com](https://katacoda.com) 创建的 [kubernetesstatus.com](http://kubernetesstatus.com/)。
|
||||
追踪Kubernetes最新特性，请访问互动教学网站提供商 [Katacoda.com](https://katacoda.com) 创建的 [kubernetesstatus.com](http://kubernetesstatus.com/)。
|
||||
|
|
@ -24,7 +24,7 @@
|
|||
|
||||
## 重定义
|
||||
|
||||
到了2018年，而随着仅几年来云原生生态的不断状态，所有主流云计算供应商都加入了该基金会，且从[Cloud Native Landscape](https://i.cncf.io)中可以看出云原生有意蚕食原先非云原生应用的部分。CNCF基金会中的会员以及容纳的项目越来越多，该定义已经限制了云原生生态的发展，CNCF为云原生进行了重新定位。
|
||||
到了2018年，随着近几年来云原生生态的不断壮大，所有主流云计算供应商都加入了该基金会，且从[Cloud Native Landscape](https://i.cncf.io)中可以看出云原生有意蚕食原先非云原生应用的部分。CNCF基金会中的会员以及容纳的项目越来越多，该定义已经限制了云原生生态的发展，CNCF为云原生进行了重新定位。
|
||||
|
||||
以下是CNCF对云原生的重新定义（中英对照）：
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ CNCF 没有偏离自己的主题，核心是解决技术问题：基金会的使
|
|||
|
||||
所谓的云原生系统须具备下面这些属性：
|
||||
|
||||
- **应用容器化**：将软件容器中的应用程序和进程作为独立的应用程序部署单元运行，并作为实现高级别资源隔离的机制。从总体上改进开发者的体验、促进代码和组件重用，而且要为云元是国内应用简化运维工作。
|
||||
- **应用容器化**：将软件容器中的应用程序和进程作为独立的应用程序部署单元运行，并作为实现高级别资源隔离的机制。从总体上改进开发者的体验、促进代码和组件重用，而且要为云原生应用简化运维工作。
|
||||
- **动态管理**：由中心化的编排来进行活跃的调度和频繁的管理，从根本上提高机器效率和资源利用率，同时降低与运维相关的成本。
|
||||
- **面向微服务**：与显式描述的依赖性松散耦合（例如通过服务端点），可以提高应用程序的整体敏捷性和可维护性。CNCF 将塑造技术的发展，推动应用管理的先进技术发展，并通过可靠的接口使技术无处不在，并且易于使用。
|
||||
|
||||
|
|
@ -352,4 +352,4 @@ CNCF社区坚信云原生计算包含三个核心属性：
|
|||
## 参考
|
||||
|
||||
- [CNCF 是如何工作的](http://www.ocselected.org/posts/foundation_introduce/how_cncf_works/)
|
||||
- https://www.cncf.io/about/charter/
|
||||
- https://www.cncf.io/about/charter/
|
||||
|
|
|
|||
|
|
@ -346,7 +346,7 @@ Service Mesh现在一般被翻译作服务网格，目前主流的Service Mesh
|
|||
|
||||
### 什么是Service Mesh
|
||||
|
||||
如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。
|
||||
如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关心服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -812,8 +812,3 @@ Deployment revision history存储在它控制的ReplicaSets中。
|
|||
|
||||
`.spec.paused`是可以可选配置项，boolean值。用来指定暂停和恢复Deployment。Paused和没有paused的Deployment之间的唯一区别就是，所有对paused deployment中的PodTemplateSpec的修改都不会触发新的rollout。Deployment被创建之后默认是非paused。
|
||||
|
||||
## Deployment 的替代选择
|
||||
|
||||
### kubectl rolling update
|
||||
|
||||
[Kubectl rolling update](https://kubernetes.io/docs/user-guide/kubectl/v1.6/#rolling-update) 虽然使用类似的方式更新Pod和ReplicationController。但是我们推荐使用Deployment，因为它是声明式的，客户端侧，具有附加特性，例如即使滚动升级结束后也可以回滚到任何历史版本。
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# 开放接口
|
||||
|
||||
Kubernetes作为云原生应用的的基础调度平台，相当于云原生的操作系统，为了便于系统的扩展，Kubernetes中开放的以下接口，可以分别对接不同的后端，来实现自己的业务逻辑：
|
||||
Kubernetes作为云原生应用的基础调度平台，相当于云原生的操作系统，为了便于系统的扩展，Kubernetes中开放的以下接口，可以分别对接不同的后端，来实现自己的业务逻辑：
|
||||
|
||||
- **CRI（Container Runtime Interface）**：容器运行时接口，提供计算资源
|
||||
- **CNI（Container Network Interface）**：容器网络接口，提供网络资源
|
||||
|
|
@ -8,4 +8,4 @@ Kubernetes作为云原生应用的的基础调度平台，相当于云原生的
|
|||
|
||||
以上三种资源相当于一个分布式操作系统的最基础的几种资源类型，而Kuberentes是将他们粘合在一起的纽带。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -127,14 +127,14 @@ spec:
|
|||
- Always：重启容器；Pod `phase` 仍为 Running。
|
||||
- OnFailure：重启容器；Pod `phase` 仍为 Running。
|
||||
- Never：Pod `phase` 变成 Failed。
|
||||
- Pod 中有两个容器并且正在运行。有一个容器退出失败。
|
||||
- Pod 中有两个容器并且正在运行。容器1退出失败。
|
||||
- 记录失败事件。
|
||||
- 如果 restartPolicy 为：
|
||||
- Always：重启容器；Pod `phase` 仍为 Running。
|
||||
- OnFailure：重启容器；Pod `phase` 仍为 Running。
|
||||
- Never：不重启容器；Pod `phase` 仍为 Running。
|
||||
|
||||
- 如果有一个容器没有处于运行状态，并且两个容器退出：
|
||||
- 如果有容器1没有处于运行状态，并且容器2退出：
|
||||
- 记录失败事件。
|
||||
- 如果 `restartPolicy` 为：
|
||||
- Always：重启容器；Pod `phase` 仍为 Running。
|
||||
|
|
|
|||
|
|
@ -1,16 +1,16 @@
|
|||
# Service Account
|
||||
|
||||
Service account为Pod中的进程提供身份信息。
|
||||
Service Account为Pod中的进程提供身份信息。
|
||||
|
||||
*本文是关于 Service Account 的用户指南，管理指南另见 Service Account 的集群管理指南 。*
|
||||
**注意**：**本文是关于 Service Account 的用户指南，管理指南另见 Service Account 的集群管理指南 。**
|
||||
|
||||
*注意：本文档描述的关于 Serivce Account 的行为只有当您按照 Kubernetes 项目建议的方式搭建起集群的情况下才有效。您的集群管理员可能在您的集群中有自定义配置，这种情况下该文档可能并不适用。*
|
||||
> 本文档描述的关于 Serivce Account 的行为只有当您按照 Kubernetes 项目建议的方式搭建起集群的情况下才有效。您的集群管理员可能在您的集群中有自定义配置，这种情况下该文档可能并不适用。
|
||||
|
||||
当您（真人用户）访问集群（例如使用`kubectl`命令）时，apiserver 会将您认证为一个特定的 User Account（目前通常是`admin`，除非您的系统管理员自定义了集群配置）。Pod 容器中的进程也可以与 apiserver 联系。 当它们在联系 apiserver 的时候，它们会被认证为一个特定的 Service Account（例如`default`）。
|
||||
|
||||
## 使用默认的 Service Account 访问 API server
|
||||
|
||||
当您创建 pod 的时候，如果您没有指定一个 service account，系统会自动得在与该pod 相同的 namespace 下为其指派一个`default` service account。如果您获取刚创建的 pod 的原始 json 或 yaml 信息（例如使用`kubectl get pods/podename -o yaml`命令），您将看到`spec.serviceAccountName`字段已经被设置为 [automatically set](https://kubernetes.io/docs/user-guide/working-with-resources/#resources-are-automatically-modified) 。
|
||||
当您创建 pod 的时候，如果您没有指定一个 service account，系统会自动得在与该pod 相同的 namespace 下为其指派一个`default` service account。如果您获取刚创建的 pod 的原始 json 或 yaml 信息（例如使用`kubectl get pods/podename -o yaml`命令），您将看到`spec.serviceAccountName`字段已经被设置为 `default`。
|
||||
|
||||
您可以在 pod 中使用自动挂载的 service account 凭证来访问 API，如 [Accessing the Cluster](https://kubernetes.io/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod) 中所描述。
|
||||
|
||||
|
|
@ -138,7 +138,7 @@ token: ...
|
|||
namespace: 7 bytes
|
||||
```
|
||||
|
||||
> 注意该内容中的`token`被省略了。
|
||||
> **注意**：该内容中的`token`被省略了。
|
||||
|
||||
## 为 service account 添加 ImagePullSecret
|
||||
|
||||
|
|
@ -154,7 +154,7 @@ myregistrykey kubernetes.io/.dockerconfigjson 1 1d
|
|||
|
||||
然后，修改 namespace 中的默认 service account 使用该 secret 作为 imagePullSecret。
|
||||
|
||||
```
|
||||
```bash
|
||||
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
|
||||
```
|
||||
|
||||
|
|
@ -205,4 +205,4 @@ spec:
|
|||
|
||||
## 参考
|
||||
|
||||
https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
|
||||
- [Configure Service Accounts for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
|
|
@ -15,13 +15,11 @@ dashboard-controller.yaml dashboard-service.yaml dashboard-rbac.yaml
|
|||
|
||||
文件中的kubernetes-dashboard-amd64镜像为本地镜像地址需要修改为对应的镜像地址和版本：
|
||||
|
||||
kubernetes 1.7.11 可以使用此镜像地址： registry.cn-qingdao.aliyuncs.com/haitao/kubernetes-dashboard-amd64:v1.7.0 替换 dashboard-controller.yaml 文件中的镜像地址
|
||||
|
||||
|
||||
kubernetes 1.7.11 可以使用此镜像地址：`registry.cn-qingdao.aliyuncs.com/haitao/kubernetes-dashboard-amd64:v1.7.0` 替换 `dashboard-controller.yaml` 文件中的镜像地址。
|
||||
|
||||
由于 `kube-apiserver` 启用了 `RBAC` 授权，而官方源码目录的 `dashboard-controller.yaml` 没有定义授权的 ServiceAccount，所以后续访问 API server 的 API 时会被拒绝，web中提示：
|
||||
|
||||
```
|
||||
```bash
|
||||
Forbidden (403)
|
||||
|
||||
User "system:serviceaccount:kube-system:default" cannot list jobs.batch in the namespace "default". (get jobs.batch)
|
||||
|
|
@ -60,7 +58,7 @@ $ diff dashboard-service.yaml.orig dashboard-service.yaml
|
|||
> type: NodePort
|
||||
```
|
||||
|
||||
+ 指定端口类型为 NodePort，这样外界可以通过地址 nodeIP:nodePort 访问 dashboard；
|
||||
+ 指定端口类型为 NodePort，这样外界可以通过地址 `nodeIP:nodePort` 访问 dashboard；
|
||||
|
||||
## 配置dashboard-controller
|
||||
|
||||
|
|
@ -201,23 +199,21 @@ Dashboard 的访问地址不变，重新访问 <http://172.20.0.113:8080/api/v1/
|
|||
|
||||
关于如何将dashboard从1.6版本升级到1.7版本请参考[升级dashboard](dashboard-upgrade.md)。
|
||||
|
||||
|
||||
|
||||
## 问题
|
||||
|
||||
1. 按照教程安装后，发现dashboard pod 无法启动
|
||||
### 1. 按照教程安装后，发现dashboard pod 无法启动
|
||||
|
||||
场景一：
|
||||
```
|
||||
kubectl -n kube-system describe pod dashboard-xxxxxxx
|
||||
```
|
||||
**场景一**
|
||||
```
|
||||
kubectl -n kube-system describe pod dashboard-xxxxxxx
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
可以尝试删除所有相关“资源”再重试一次，如：secret、serviceaccount、service、pod、deployment
|
||||
可以尝试删除所有相关“资源”再重试一次，如：secret、serviceaccount、service、pod、deployment
|
||||
|
||||
**场景二**
|
||||
|
||||
场景二：
|
||||
```bash
|
||||
kubectl describe pod -n kube-system kubernetes-dashboard-7b7bf9bcbd-xxxxx
|
||||
Events:
|
||||
|
|
@ -228,8 +224,10 @@ Dashboard 的访问地址不变，重新访问 <http://172.20.0.113:8080/api/v1/
|
|||
Warning FailedMount 17s (x7 over 49s) kubelet, 192.168.1.101 MountVolume.SetUp failed for volume "kubernetes-dashboard-certs" : secrets "kubernetes-dashboard-certs" is forbidden: User "system:node:192.168.1.233" cannot get secrets in the namespace "kube-system": no path found to object
|
||||
Warning FailedMount 17s (x7 over 49s) kubelet, 192.168.1.101 MountVolume.SetUp failed for volume "kubernetes-dashboard-token-27kdp" : secrets "kubernetes-dashboard-token-27kdp" is forbidden: User "system:node:192.168.1.233" cannot get secrets in the namespace "kube-system": no path found to object
|
||||
```
|
||||
通过官方文档：[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions)。可以了解到，对于k8s1.8+版本，system:node不会进行默认绑定。因此对于分配到其他node的pod，会出现forbidden。
|
||||
需要手动bind各个node：
|
||||
通过官方文档：[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions)。可以了解到，对于k8s1.8+版本，system:node不会进行默认绑定。因此对于分配到其他node的pod，会出现forbidden。
|
||||
|
||||
需要手动bind各个node：
|
||||
|
||||
```bash
|
||||
kubectl create clusterrolebinding node233 --clusterrole=system:node --user=system:node:192.168.1.233
|
||||
kubectl describe pod -n kube-system kubernetes-dashboard-7b7bf9bcbd-xxxxx
|
||||
|
|
@ -243,6 +241,10 @@ Dashboard 的访问地址不变，重新访问 <http://172.20.0.113:8080/api/v1/
|
|||
Normal Pulling 15s kubelet, 192.168.1.101 pulling image "registry.cn-hangzhou.aliyuncs.com/google_containers/kubernetes-dashboard-amd64:v1.8.3"
|
||||
```
|
||||
|
||||
### 2. 自定义dashboard启动参数
|
||||
|
||||
可以在dashboard的YAML文件中配置[启动参数](https://github.com/kubernetes/dashboard/wiki/Dashboard-arguments)，比如设置token的默认过期时间、heapster地址、绑定的证书等。
|
||||
|
||||
## 参考
|
||||
|
||||
- [WebUI(Dashboard) 文档](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/)
|
||||
|
|
@ -206,7 +206,7 @@ KUBELET_HOSTNAME="--hostname-override=172.20.0.113"
|
|||
KUBELET_API_SERVER="--api-servers=http://172.20.0.113:8080"
|
||||
#
|
||||
## pod infrastructure container
|
||||
KUBELET_POD_INFRA_CONTAINER="--pod-infra-container-image=harbor-001.jimmysong.io/library/pod-infrastructure:rhel7"
|
||||
KUBELET_POD_INFRA_CONTAINER="--pod-infra-container-image=jimmysong/pause-amd64:3.0"
|
||||
#
|
||||
## Add your own!
|
||||
KUBELET_ARGS="--cgroup-driver=systemd --cluster-dns=10.254.0.2 --experimental-bootstrap-kubeconfig=/etc/kubernetes/bootstrap.kubeconfig --kubeconfig=/etc/kubernetes/kubelet.kubeconfig --require-kubeconfig --cert-dir=/etc/kubernetes/ssl --cluster-domain=cluster.local --hairpin-mode promiscuous-bridge --serialize-image-pulls=false"
|
||||
|
|
@ -236,7 +236,7 @@ systemctl start kubelet
|
|||
systemctl status kubelet
|
||||
```
|
||||
|
||||
### 通过 kublet 的 TLS 证书请求
|
||||
### 通过kublet的TLS证书请求
|
||||
|
||||
kubelet 首次启动时向 kube-apiserver 发送证书签名请求，必须通过后 kubernetes 系统才会将该 Node 加入到集群。
|
||||
|
||||
|
|
@ -341,7 +341,7 @@ systemctl status kube-proxy
|
|||
我们创建一个nginx的service试一下集群是否可用。
|
||||
|
||||
```bash
|
||||
$ kubectl run nginx --replicas=2 --labels="run=load-balancer-example" --image=harbor-001.jimmysong.io/library/nginx:1.9 --port=80
|
||||
$ kubectl run nginx --replicas=2 --labels="run=load-balancer-example" --image=nginx --port=80
|
||||
deployment "nginx" created
|
||||
$ kubectl expose deployment nginx --type=NodePort --name=example-service
|
||||
service "example-service" exposed
|
||||
|
|
@ -386,12 +386,14 @@ Commercial support is available at
|
|||
</html>
|
||||
```
|
||||
|
||||
提示：上面的测试示例中使用的nginx是我的私有镜像仓库中的镜像`harbor-001.jimmysong.io/library/nginx:1.9`，大家在测试过程中请换成自己的nginx镜像地址。
|
||||
访问以下任何一个地址都可以得到nginx的页面。
|
||||
|
||||
访问`172.20.0.113:32724`或`172.20.0.114:32724`或者`172.20.0.115:32724`都可以得到nginx的页面。
|
||||
- 172.20.0.113:32724
|
||||
- 172.20.0.114:32724
|
||||
- 172.20.0.115:32724
|
||||
|
||||
|
||||
|
||||
|
||||
## 参考
|
||||
|
||||
[Kubelet 的认证授权](../guide/kubelet-authentication-authorization.md)
|
||||
- [Kubelet 的认证授权](../guide/kubelet-authentication-authorization.md)
|
||||
|
|
@ -1,6 +1,8 @@
|
|||
# Istio简介
|
||||
|
||||
[Istio](https://istio.io)是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。Istio为希腊语，意思是”起航“。关于Istio的详细信息请参考[Istio官方文档](https://istio.io)和[Istio中文文档](http://istio.doczh.cn)。
|
||||
> **注意**：Istio 1.10于2018年8月1日发布1.0，关于Istio的更多信息请见Istio官方文档:<https://istio.io>，中文版：<https://istio.io/zh>。
|
||||
|
||||
[Istio](https://istio.io)是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。Istio为希腊语，意思是”起航“。
|
||||
|
||||
**TL;DR** 关于Istio中的各个组件和一些关键信息请参考下面的mindmap。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
# Linkerd简介
|
||||
|
||||
> **注意**：Linkerd最初版本是使用Scala开发的，现在已开始开发Linkerd2，使用Go语言开发，该公司的另一款轻量级Service Mesh conduit也寿终正寝，合并入Linkerd 2.0，详见[Conduit 0.5发布—以及R.I.P. Conduit](http://www.servicemesher.com/blog/rip-conduit/)。
|
||||
|
||||
Linkerd是一个用于云原生应用的开源、可扩展的service mesh（一般翻译成服务网格，还有一种说法叫”服务啮合层“，见[Istio：用于微服务的服务啮合层](http://www.infoq.com/cn/news/2017/05/istio)）。
|
||||
|
||||
## Linkerd是什么
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
|
||||
TL;DR 这个主题比较大，该开源项目也还在不断进行中，我单独做了一个 web 用来记录 spark on kubernetes 的研究和最新进展见: https://jimmysong.io/spark-on-k8s
|
||||
|
||||
**注意**：本文中的镜像仓库地址 `harbor-001.jimmysong.io` 为的镜像仓库地址为伪装地址，非本文中真正使用的镜像仓库，且该地址也不存在，请替换为您自己的镜像仓库。
|
||||
|
||||
我们之前就在 kubernetes 中运行过 standalone 方式的 spark 集群，见 [Spark standalone on kubernetes](spark-standalone-on-kubernetes.md)。
|
||||
|
||||
目前运行支持 kubernetes 原生调度的 spark 程序由 Google 主导，目前运行支持 kubernetes 原生调度的 spark 程序由 Google 主导，fork 自 spark 的官方代码库，见https://github.com/apache-spark-on-k8s/spark/ ，属于Big Data SIG。
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
SOFAMesh由蚂蚁金服开源，在兼容Istio整体架构和协议的基础上，做出部分调整：
|
||||
|
||||
|
||||
|
||||
|
||||
1. **使用Go语言开发全新的Sidecar，替代Envoy**
|
||||
2. **为了避免Mixer带来的性能瓶颈，合并Mixer部分功能进入Sidecar**
|
||||
|
|
@ -40,12 +40,15 @@ SOFAMesh中Golang版本的Sidecar，是一个名为MOSN(Modular Observable Smart
|
|||
|
||||
MOSN和SOFAPilot配合，将可以提供让传统侵入式框架（如Spring Cloud，Dubbo，SOFA RPC等）和Service Mesh产品可以相互通讯的功能，以便可以平滑的向Service Mesh产品演进和过渡。
|
||||
|
||||
**Pilot和后面会陆续开放的Mixer，Citadel等Istio模块**，会统一存放在同一个从Istio Fork出来的代码仓库中。未来会持续更新Istio最新代码，以保持和Istio的一致。
|
||||
**Pilot和后面会陆续开放的Mixer\Citadel等Istio模块**，会统一存放在同一个从Istio Fork出来的代码仓库中。未来会持续更新Istio最新代码，以保持和Istio的一致。
|
||||
|
||||
## Roadmap
|
||||
|
||||
|
||||
|
||||
## 参考
|
||||
|
||||
- [SOFA MOSN](https://github.com/alipay/sofa-mosn)
|
||||
- [SOFAMesh](https://github.com/alipay/sofa-mesh)
|
||||
- [SOFAMesh官方网站](http://www.sofastack.tech/)
|
||||
- [SOFAMesh官方文档](http://www.sofastack.tech/sofa-mesh/docs/Hom)
|
||||
- [SOFAMesh官方文档](http://www.sofastack.tech/sofa-mesh/docs/Home)
|
||||
- [蚂蚁金服大规模微服务架构下的Service Mesh探索之路](http://www.servicemesher.com/blog/the-way-to-service-mesh-in-ant-financial/)
|
||||
Loading…
Reference in New Issue