fix lint errors
Jimmy song
parent
0015615f56
commit
2f739b79cc
|
|
@ -29,7 +29,7 @@
|
|||
**可扩展性**
|
||||
|
||||
- 运行时的[API聚合](https://kubernetes.io/docs/concepts/api-extension/apiserver-aggregation/)是此版本中最强大的扩展功能，允许高级用户将Kubernetes风格的预先构建的第三方或用户创建的API添加到其集群中。
|
||||
- [容器运行时接口](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md)（CRI）已经增强，可以使用新的RPC调用从运行时检索容器度量。 [CRI的验证测试](https://github.com/kubernetes/community/blob/master/contributors/devel/cri-validation.md)已经发布，与[containerd](http://containerd.io/)进行了Alpha集成，现在支持基本的生命周期和镜像管理。参考[深入介绍CRI](http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html)的文章。
|
||||
- [容器运行时接口](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md)（CRI）已经增强，可以使用新的RPC调用从运行时检索容器度量。 CRI的验证测试已经发布，与[containerd](http://containerd.io/)进行了Alpha集成，现在支持基本的生命周期和镜像管理。参考[深入介绍CRI](http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html)的文章。
|
||||
|
||||
**其它功能**
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Deployment和ReplicaSet是Kubernetes中最常用的两个对象，经过一年
|
|||
|
||||
## Windows支持（beta）
|
||||
|
||||
Kubernetes最初是为Linux系统开发的，但是用户逐渐意识到容器编排的好处，我们看到有人需要在Kubernetes上运行Windows工作负载。在12个月前，我们开始认真考虑在Kubernetes上支持Windows Server的工作。 [SIG-Windows](https://github.com/kubernetes/community/tree/master/sig-windows)现在已经将这个功能推广到beta版本，这意味着我们可以评估它的[使用情况](https://kubernetes.io/docs/getting-started-guides/windows/)。
|
||||
Kubernetes最初是为Linux系统开发的，但是用户逐渐意识到容器编排的好处，我们看到有人需要在Kubernetes上运行Windows工作负载。在12个月前，我们开始认真考虑在Kubernetes上支持Windows Server的工作。 [SIG-Windows](https://github.com/kubernetes/community/tree/master/sig-windows)现在已经将这个功能推广到beta版本，这意味着我们可以评估它的使用情况。
|
||||
|
||||
## 增强存储
|
||||
|
||||
|
|
|
|||
|
|
@ -126,7 +126,3 @@ storage.k8s.io/v1
|
|||
storage.k8s.io/v1beta1
|
||||
v1
|
||||
```
|
||||
|
||||
## 参考
|
||||
|
||||
- [API Conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#resources)
|
||||
|
|
|
|||
|
|
@ -14,8 +14,6 @@ Container Runtime实现了CRI gRPC Server，包括`RuntimeService`和`ImageServi
|
|||
|
||||
要想启用CRI只需要在kubelet的启动参数重传入此参数：`--container-runtime-endpoint`远程运行时服务的端点。当前Linux上支持unix socket，windows上支持tcp。例如：`unix:///var/run/dockershim.sock`、 `tcp://localhost:373`，默认是`unix:///var/run/dockershim.sock`，即默认使用本地的docker作为容器运行时。
|
||||
|
||||
关于CRI的详细进展请参考[CRI: the Container Runtime Interface](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md)。
|
||||
|
||||
## CRI接口
|
||||
|
||||
Kubernetes 1.9中的CRI接口在`api.proto`中的定义如下：
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@
|
|||
|
||||
### 必需字段
|
||||
|
||||
和其它所有 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata`字段。有关配置文件的通用信息，详见文档 [部署应用](https://kubernetes.io/docs/user-guide/deploying-applications/)、[配置容器](https://kubernetes.io/docs/user-guide/configuring-containers/) 和 [资源管理](https://kubernetes.io/docs/concepts/tools/kubectl/object-management-overview/) 。
|
||||
和其它所有 Kubernetes 配置一样，DaemonSet 需要 `apiVersion`、`kind` 和 `metadata`字段。有关配置文件的通用信息，详见文档 [部署应用](https://kubernetes.io/docs/user-guide/deploying-applications/)、[配置容器](https://kubernetes.io/docs/user-guide/configuring-containers/) 和资源管理。
|
||||
|
||||
DaemonSet 也需要一个 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 配置段。
|
||||
|
||||
|
|
|
|||
|
|
@ -722,7 +722,7 @@ $ echo $?
|
|||
|
||||
## 编写 Deployment Spec
|
||||
|
||||
在所有的 Kubernetes 配置中，Deployment 也需要`apiVersion`，`kind`和`metadata`这些配置项。配置文件的通用使用说明查看 [部署应用](https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/)，配置容器，和 [使用 kubectl 管理资源 ](https://kubernetes.io/docs/tutorials/object-management-kubectl/object-management/) 文档。
|
||||
在所有的 Kubernetes 配置中，Deployment 也需要`apiVersion`，`kind`和`metadata`这些配置项。配置文件的通用使用说明查看 [部署应用](https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/)，配置容器，和使用 kubectl 管理资源文档。
|
||||
|
||||
### Pod Template
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
### Kubernetes中的网络解析——以flannel为例
|
||||
# Kubernetes中的网络解析——以flannel为例
|
||||
|
||||
我们当初使用[kubernetes-vagrant-centos-cluster](https://github.com/rootsongjc/kubernetes-vagrant-centos-cluster)安装了拥有三个节点的kubernetes集群，节点的状态如下所述。
|
||||
|
||||
|
|
@ -382,13 +382,12 @@ Chain KUBE-SERVICES (2 references)
|
|||
target prot opt source destination
|
||||
```
|
||||
|
||||
从上面的iptables中可以看到注入了很多Kuberentes service的规则，请参考[iptables 规则](https://www.cnyunwei.cc/archives/393)获取更多详细信息。
|
||||
从上面的iptables中可以看到注入了很多Kuberentes service的规则。
|
||||
|
||||
## 参考
|
||||
|
||||
- [coreos/flannel - github.com](https://github.com/coreos/flannel)
|
||||
- [linux 网络虚拟化： network namespace 简介](http://cizixs.com/2017/02/10/network-virtualization-network-namespace)
|
||||
- [Linux虚拟网络设备之veth](https://segmentfault.com/a/1190000009251098)
|
||||
- [iptables 规则](https://www.cnyunwei.cc/archives/393)
|
||||
- [flannel host-gw network](http://hustcat.github.io/flannel-host-gw-network/)
|
||||
- [flannel - openshift.com](https://docs.openshift.com/container-platform/3.4/architecture/additional_concepts/flannel.html)
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ GCE/GKE会在master节点上部署一个ingress controller。你可以在一个p
|
|||
|
||||
**1-4行**：跟Kubernetes的其他配置一样，ingress的配置也需要`apiVersion`，`kind`和`metadata`字段。配置文件的详细说明请查看[部署应用](https://kubernetes.io/docs/user-guide/deploying-applications), [配置容器](https://kubernetes.io/docs/user-guide/configuring-containers)和 [使用resources](https://kubernetes.io/docs/user-guide/working-with-resources).
|
||||
|
||||
**5-7行**: Ingress [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status) 中包含配置一个loadbalancer或proxy server的所有信息。最重要的是，它包含了一个匹配所有入站请求的规则列表。目前ingress只支持http规则。
|
||||
**5-7行**: Ingress spec 中包含配置一个loadbalancer或proxy server的所有信息。最重要的是，它包含了一个匹配所有入站请求的规则列表。目前ingress只支持http规则。
|
||||
|
||||
**8-9行**：每条http规则包含以下信息：一个`host`配置项（比如for.bar.com，在这个例子中默认是*），`path`列表（比如：/testpath），每个path都关联一个`backend`(比如test:80)。在loadbalancer将流量转发到backend之前，所有的入站请求都要先匹配host和path。
|
||||
|
||||
|
|
|
|||
|
|
@ -55,9 +55,9 @@ spec:
|
|||
|
||||
*将上面配置 POST 到 API Server 将不起任何作用，除非选择的网络方案支持网络策略。*
|
||||
|
||||
**必选字段**：像所有其它 Kubernetes 配置一样， `NetworkPolicy` 需要 `apiVersion`、`kind` 和 `metadata` 这三个字段，关于如何使用配置文件的基本信息，可以查看 [这里](https://kubernetes.io/docs/user-guide/configuring-containers) 和 [这里](https://kubernetes.io/docs/user-guide/working-with-resources)。
|
||||
**必选字段**：像所有其它 Kubernetes 配置一样， `NetworkPolicy` 需要 `apiVersion`、`kind` 和 `metadata` 这三个字段，关于如何使用配置文件的基本信息，可以查看 [这里](https://kubernetes.io/docs/user-guide/configuring-containers)。
|
||||
|
||||
**spec**：`NetworkPolicy` [spec](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) 具有在给定 Namespace 中定义特定网络的全部信息。
|
||||
**spec**：`NetworkPolicy` spec 具有在给定 Namespace 中定义特定网络的全部信息。
|
||||
|
||||
**podSelector**：每个 `NetworkPolicy` 包含一个 `podSelector`，它可以选择一组应用了网络策略的 Pod。由于 `NetworkPolicy` 当前只支持定义 `ingress` 规则，这个 `podSelector` 实际上为该策略定义了一组 “目标Pod”。示例中的策略选择了标签为 “role=db” 的 Pod。一个空的 `podSelector` 选择了该 Namespace 中的所有 Pod。
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@
|
|||
|
||||
Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernetes 系统将持续工作以确保对象存在。通过创建对象，可以有效地告知 Kubernetes 系统，所需要的集群工作负载看起来是什么样子的，这就是 Kubernetes 集群的 **期望状态**。
|
||||
|
||||
与 Kubernetes 对象工作 —— 是否创建、修改，或者删除 —— 需要使用 [Kubernetes API](https://git.k8s.io/community/contributors/devel/api-conventions.md)。当使用 `kubectl` 命令行接口时，比如，CLI 会使用必要的 Kubernetes API 调用，也可以在程序中直接使用 Kubernetes API。为了实现该目标，Kubernetes 当前提供了一个 `golang` [客户端库](https://github.com/kubernetes/client-go) ，其它语言库（例如[Python](https://github.com/kubernetes-incubator/client-python)）也正在开发中。
|
||||
与 Kubernetes 对象工作 —— 是否创建、修改，或者删除 —— 需要使用 Kubernetes API。当使用 `kubectl` 命令行接口时，比如，CLI 会使用必要的 Kubernetes API 调用，也可以在程序中直接使用 Kubernetes API。为了实现该目标，Kubernetes 当前提供了一个 `golang` [客户端库](https://github.com/kubernetes/client-go) ，其它语言库（例如[Python](https://github.com/kubernetes-incubator/client-python)）也正在开发中。
|
||||
|
||||
### 对象 Spec 与状态
|
||||
|
||||
|
|
|
|||
|
|
@ -689,8 +689,6 @@ spec:
|
|||
|
||||
`FlexVolume`使用户能够将供应商卷挂载到容器中。供应商插件是使用驱动程序实现的，该驱动程序支持由 `FlexVolume` API定义的一系列卷命令。驱动程序必须安装在每个节点的预定义卷插件路径中。
|
||||
|
||||
更多细节可以在[这里](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md)找到。
|
||||
|
||||
## 挂载传播
|
||||
|
||||
**注意**：挂载传播是 Kubernetes 1.8 中的一个 alpha 特性，在将来的版本中可能会重新设计甚至删除。
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
|
||||
Kubebuilder 是一个基于 [CRD](../concepts/crd.md) 来构建 Kubernetes API 的框架，可以使用 CRD 来构建 API、Controller 和 Admission Webhook。
|
||||
|
||||
请参考 [Kubebuilder quick start](https://book.kubebuilder.io/quick_start.html) 来安装 kubebuilder。
|
||||
|
||||
## 动机
|
||||
|
||||
目前扩展 Kubernetes 的 API 的方式有创建 [CRD](../concepts/crd.md)、使用 [Operator](operator.md) SDK 等方式，都需要写很多的样本文件（boilerplate），使用起来十分麻烦。为了能够更方便构建 Kubernetes API 和工具，就需要一款能够事半功倍的工具，与其他 Kubernetes API 扩展方案相比，kubebuilder 更加简单易用，并获得了社区的广泛支持。
|
||||
|
|
|
|||
|
|
@ -199,8 +199,4 @@ kubectl get pods nginx-4263166205-ggst4 -o template '--template={{if (exists . "
|
|||
|
||||
## 参考文档
|
||||
|
||||
* [Kubernetes testing](https://github.com/kubernetes/community/blob/master/contributors/devel/testing.md)
|
||||
* [End-to-End Testing](https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-tests.md)
|
||||
* [Node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-node-tests.md)
|
||||
* [How to write e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/writing-good-e2e-tests.md)
|
||||
* https://github.com/kubernetes/test-infra
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
## 访问集群
|
||||
# 访问集群
|
||||
|
||||
### 第一次使用 kubectl 访问
|
||||
## 第一次使用 kubectl 访问
|
||||
|
||||
如果您是第一次访问 Kubernetes API 的话，我们建议您使用 Kubernetes 命令行工具：`kubectl`。
|
||||
|
||||
为了访问集群，您需要知道集群的地址，并且需要有访问它的凭证。通常，如果您完成了 [入门指南](https://kubernetes.io/docs/getting-started-guides) 那么这些将会自动设置，或者其他人为您部署的集群提供并给您凭证和集群地址。
|
||||
为了访问集群，您需要知道集群的地址，并且需要有访问它的凭证。通常，如果您完成了入门指南那么这些将会自动设置，或者其他人为您部署的集群提供并给您凭证和集群地址。
|
||||
|
||||
使用下面的命令检查 kubectl 已知的集群的地址和凭证：
|
||||
|
||||
|
|
@ -12,7 +12,7 @@
|
|||
$ kubectl config view
|
||||
```
|
||||
|
||||
### 直接访问 REST API
|
||||
## 直接访问 REST API
|
||||
|
||||
Kubectl 处理对 apiserver 的定位和认证。如果您想直接访问 REST API，可以使用像 curl、wget 或浏览器这样的 http 客户端，有以下几种方式来定位和认证：
|
||||
|
||||
|
|
@ -27,7 +27,7 @@ Kubectl 处理对 apiserver 的定位和认证。如果您想直接访问 REST A
|
|||
- 适用于通过使用代理而混淆的某些类型的客户端代码。
|
||||
- 需要将根证书导入浏览器以防止 MITM。
|
||||
|
||||
#### 使用 kubectl proxy
|
||||
### 使用 kubectl proxy
|
||||
|
||||
以下命令作为反向代理的模式运行 kubectl。 它处理对 apiserver 的定位并进行认证。
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ $ curl http://localhost:8080/api/
|
|||
}
|
||||
```
|
||||
|
||||
#### 不使用 kubectl proxy（1.3.x 以前版本）
|
||||
### 不使用 kubectl proxy（1.3.x 以前版本）
|
||||
|
||||
通过将认证 token 直接传递给 apiserver 的方式，可以避免使用 kubectl proxy，如下所示：
|
||||
|
||||
|
|
@ -63,7 +63,7 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
|||
}
|
||||
```
|
||||
|
||||
#### 不使用 kubectl proxy（1.3.x 以后版本）
|
||||
### 不使用 kubectl proxy（1.3.x 以后版本）
|
||||
|
||||
在 Kubernetes 1.3 或更高版本中，`kubectl config view` 不再显示 token。 使用 `kubectl describe secret …` 获取 default service account 的 token，如下所示：
|
||||
|
||||
|
|
@ -89,11 +89,11 @@ $ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
|
|||
|
||||
对于某些群集，apiserver 可能不需要身份验证；可以选择在本地主机上服务，或者使用防火墙保护。 对此还没有一个标准。[配置对API的访问](https://kubernetes.io/docs/admin/accessing-the-api) 描述了群集管理员如何配置此操作。 这种方法可能与未来的高可用性支持相冲突。
|
||||
|
||||
### 编程访问 API
|
||||
## 编程访问 API
|
||||
|
||||
Kubernetes 支持 [Go](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster.md#go-client) 和 [Python](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster.md#python-client) 客户端库。
|
||||
|
||||
#### Go 客户端
|
||||
### Go 客户端
|
||||
|
||||
- 要获取该库，请运行以下命令：`go get k8s.io/client-go/<version number>/kubernetes` 请参阅 [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go) 以查看支持哪些版本。
|
||||
- 使用 client-go 客户端编程。请注意，client-go 定义了自己的 API 对象，因此如果需要，请从 client-go 而不是从主存储库导入 API 定义，例如导入 `k8s.io/client-go/1.4/pkg/api/v1` 是正确的。
|
||||
|
|
@ -102,17 +102,17 @@ Go 客户端可以使用与 kubectl 命令行工具相同的 [kubeconfig 文件]
|
|||
|
||||
如果应用程序在群集中以 Pod 的形式部署，请参考 [下一节](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster.md#accessing-the-api-from-a-pod)。
|
||||
|
||||
#### Python 客户端
|
||||
### Python 客户端
|
||||
|
||||
要使用 [Python client](https://github.com/kubernetes-incubator/client-python)，请运行以下命令：`pip install kubernetes`。查看 [Python 客户端库页面](https://github.com/kubernetes-incubator/client-python) 获取更多的安装选择。
|
||||
|
||||
Python 客户端可以使用与 kubectl 命令行工具相同的 [kubeconfig 文件](https://kubernetes.io/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig) 来定位和验证 apiserver。参考该 [示例](https://github.com/kubernetes-incubator/client-python/tree/master/examples/example1.py)。
|
||||
|
||||
#### 其他语言
|
||||
### 其他语言
|
||||
|
||||
还有更多的客户端库可以用来访问 API。有关其他库的验证方式，请参阅文档。
|
||||
|
||||
### 在 Pod 中访问 API
|
||||
## 在 Pod 中访问 API
|
||||
|
||||
在 Pod 中访问 API 时，定位和认证到 API server 的方式有所不同。在 Pod 中找到 apiserver 地址的推荐方法是使用kubernetes DNS 名称，将它解析为服务 IP，后者又将被路由到 apiserver。
|
||||
|
||||
|
|
@ -183,7 +183,7 @@ $ kubectl cluster-info
|
|||
|
||||
如果您没有指定 port 的名字，那么您不必在 URL 里指定 port_name。
|
||||
|
||||
##### 示例
|
||||
#### 示例
|
||||
|
||||
- 要想访问 Elasticsearch 的服务端点 `_search?q=user:kimchy`，您需要使用：`http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`
|
||||
- 要想访问 Elasticsearch 的集群健康信息 `_cluster/health?pretty=true`，您需要使用：`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`
|
||||
|
|
|
|||
|
|
@ -136,8 +136,6 @@ spec:
|
|||
|
||||
任何大于200小于400的返回码都会认定是成功的返回码。其他返回码都会被认为是失败的返回码。
|
||||
|
||||
查看该server的源码：[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/liveness/server.go).
|
||||
|
||||
最开始的10秒该容器是活着的， `/healthz` handler返回200的状态码。这之后将返回500的返回码。
|
||||
|
||||
```go
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Service account 为 Pod 中的进程提供身份信息。
|
|||
|
||||
## 使用默认的 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`字段已经被设置为 automatically 。
|
||||
|
||||
您可以在 pod 中使用自动挂载的 service account 凭证来访问 API，如 [Accessing the Cluster](https://kubernetes.io/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod) 中所描述。
|
||||
|
||||
|
|
|
|||
|
|
@ -276,7 +276,7 @@ $ kubectl taint nodes foo dedicated=special-user:NoSchedule
|
|||
|
||||
### Kubectl 详细输出和调试
|
||||
|
||||
使用 `-v` 或 `--v` 标志跟着一个整数来指定日志级别。[这里](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md) 描述了通用的 kubernetes 日志约定和相关的日志级别。
|
||||
使用 `-v` 或 `--v` 标志跟着一个整数来指定日志级别。
|
||||
|
||||
| 详细等级 | 描述 |
|
||||
| ------- | ---------------------------------------- |
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
|
|
@ -406,5 +406,4 @@ cp *.pem /etc/kubernetes/ssl
|
|||
|
||||
+ [Generate self-signed certificates](https://coreos.com/os/docs/latest/generate-self-signed-certificates.html)
|
||||
+ [Client Certificates V/s Server Certificates](https://blogs.msdn.microsoft.com/kaushal/2012/02/17/client-certificates-vs-server-certificates/)
|
||||
+ [数字证书及 CA 的扫盲介绍](http://blog.jobbole.com/104919/)
|
||||
+ [TLS bootstrap 引导程序](../guide/tls-bootstrapping.md)
|
||||
|
|
|
|||
|
|
@ -560,7 +560,7 @@ kubectl repalce -f ingress.yaml
|
|||
|
||||
然后在本地的`/etc/hosts`文件中增加一条配置：
|
||||
|
||||
```Ini
|
||||
```ini
|
||||
172.20.0.119 mean.jimmysong.io
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -125,7 +125,7 @@ KUBE_MASTER="--master=http://172.20.0.113:8080"
|
|||
|
||||
apiserver配置文件`/etc/kubernetes/apiserver`内容为：
|
||||
|
||||
``` Ini
|
||||
```ini
|
||||
###
|
||||
## kubernetes system config
|
||||
##
|
||||
|
|
@ -213,7 +213,7 @@ WantedBy=multi-user.target
|
|||
|
||||
配置文件`/etc/kubernetes/controller-manager`。
|
||||
|
||||
``` ini
|
||||
```ini
|
||||
###
|
||||
# The following values are used to configure the kubernetes controller-manager
|
||||
|
||||
|
|
@ -282,7 +282,7 @@ WantedBy=multi-user.target
|
|||
|
||||
配置文件`/etc/kubernetes/scheduler`。
|
||||
|
||||
``` Ini
|
||||
```ini
|
||||
###
|
||||
# kubernetes scheduler config
|
||||
|
||||
|
|
|
|||
|
|
@ -397,5 +397,4 @@ Locust模拟10万用户，每秒增长100个。
|
|||
- [Kubernetes集群性能测试](https://supereagle.github.io/2017/03/09/kubemark/)
|
||||
- [CoreOS是如何将Kubernetes的性能提高10倍的](http://dockone.io/article/1050)
|
||||
- [运用Kubernetes进行分布式负载测试](http://www.csdn.net/article/2015-07-07/2825155)
|
||||
- [Kubemark User Guide](https://github.com/kubernetes/community/blob/master/contributors/devel/kubemark-guide.md)
|
||||
- [Flannel host-gw architecture](https://docs.openshift.com/container-platform/3.4/architecture/additional_concepts/flannel.html)
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ Deployment同样为Kubernetes的一个核心内容，主要职责同样是为了
|
|||
|
||||
**Web服务的代码main.go**
|
||||
|
||||
```Go
|
||||
```go
|
||||
package main
|
||||
|
||||
import (
|
||||
|
|
|
|||
|
|
@ -124,10 +124,7 @@ curl -sX GET -H "Authorization:bearer `cat /var/run/secrets/kubernetes.io/servic
|
|||
|
||||
不需要指定 csr 文件，只需要 token 即可。
|
||||
|
||||
参考 [wait-for-endpoints init-containers fails to load with k8s 1.6.0 #56](https://github.com/giantswarm/kubernetes-prometheus/issues/56)
|
||||
|
||||
## 参考
|
||||
|
||||
- [Kubernetes Setup for Prometheus and Grafana](https://github.com/giantswarm/kubernetes-prometheus)
|
||||
- [RBAC——基于角色的访问控制](../guide/rbac.md)
|
||||
- [wait-for-endpoints init-containers fails to load with k8s 1.6.0 #56](https://github.com/giantswarm/kubernetes-prometheus/issues/56)
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Vizceral有两个可视化级别，全局可视化和集群级别可视化。在
|
|||
|
||||
**前言**
|
||||
|
||||
如果您还尚未部署服务网格，可以按照此[Istio Bookinfo Demo](https://istio.io/docs/guides/bookinfo/)中的说明部署Istio及其示例应用程序。您需要能够在应用程序之间生成流量。要测试指标是否从Mixer正确发送到Prometheus，您可以运行以下Prometheus查询`istio_request_count`，应该会看到多个条目。
|
||||
如果您还尚未部署服务网格，可以按照Istio Bookinfo Demo 中的说明部署Istio及其示例应用程序。您需要能够在应用程序之间生成流量。要测试指标是否从Mixer正确发送到Prometheus，您可以运行以下Prometheus查询`istio_request_count`，应该会看到多个条目。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ X-protocol 的定位是云原生、高性能、低侵入性的通用 Service Mes
|
|||
|
||||
先看部署效果图：
|
||||
|
||||
|
||||
|
||||
|
||||
本示例中dubbo-consumer的部署方式采用直连模式，即不走注册中心，完全依托kubernetes平台提供的服务注册及服务发现能力。
|
||||
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@
|
|||
|
||||
第一步开始时，`productpage` Pod 中的 Envoy sidecar 已经通过 EDS 选择出了要请求的 `reviews` 服务的一个 Pod，知晓了其 IP 地址，发送 TCP 连接请求。
|
||||
|
||||
Istio 官网中的 [Envoy 配置深度解析](https://preliminary.istio.io/zh/help/ops/traffic-management/proxy-cmd/#envoy-%E9%85%8D%E7%BD%AE%E6%B7%B1%E5%BA%A6%E8%A7%A3%E6%9E%90)中是以发起 HTTP 请求的一方来详述 Envoy 做流量转发的过程，而本文中考虑的是接受 downstream 的流量的一方，它既要接收 downstream 发来的请求，自己还需要请求其他服务，例如 `reviews` 服务中的 Pod 还需要请求 `ratings` 服务。
|
||||
Istio 官网中的 Envoy 配置深度解析中是以发起 HTTP 请求的一方来详述 Envoy 做流量转发的过程，而本文中考虑的是接受 downstream 的流量的一方，它既要接收 downstream 发来的请求，自己还需要请求其他服务，例如 `reviews` 服务中的 Pod 还需要请求 `ratings` 服务。
|
||||
|
||||
`reviews` 服务有三个版本，每个版本有一个实例，三个版本中的 sidecar 工作步骤类似，下文只以 `reviews-v1-cb8655c75-b97zc` 这一个 Pod 中的 Sidecar 流量转发步骤来说明。
|
||||
|
||||
|
|
@ -270,7 +270,7 @@ ADDRESS PORT TYPE
|
|||
|
||||
因为 `reviews` 会向 `ratings` 服务发送 HTTP 请求，请求的地址是：`http://ratings.default.svc.cluster.local:9080/`，Outbound handler 的作用是将 iptables 拦截到的本地应用程序发出的流量，经由 Envoy 判断如何路由到 upstream。
|
||||
|
||||
应用程序容器发出的请求为 Outbound 流量，被 iptables 劫持后转移给 Envoy Outbound handler 处理，然后经过 `virtual` Listener、`0.0.0.0_9080` Listener，然后通过 Route 9080 找到 upstream 的 cluster，进而通过 EDS 找到 Endpoint 执行路由动作。这一部分可以参考 Istio 官网中的 [Envoy 深度配置解析](https://preliminary.istio.io/zh/help/ops/traffic-management/proxy-cmd/#envoy-%E9%85%8D%E7%BD%AE%E6%B7%B1%E5%BA%A6%E8%A7%A3%E6%9E%90)。
|
||||
应用程序容器发出的请求为 Outbound 流量，被 iptables 劫持后转移给 Envoy Outbound handler 处理，然后经过 `virtual` Listener、`0.0.0.0_9080` Listener，然后通过 Route 9080 找到 upstream 的 cluster，进而通过 EDS 找到 Endpoint 执行路由动作。
|
||||
|
||||
**Route 9080**
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@
|
|||
|
||||
**Upstream**：上游（upstream）主机获取来自 Envoy 的链接请求和响应。
|
||||
|
||||
**Cluster**: 集群（cluster）是 Envoy 连接到的一组逻辑上相似的上游主机。Envoy 通过[服务发现](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/service_discovery#arch-overview-service-discovery)发现集群中的成员。Envoy 可以通过[主动运行状况检查](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/health_checking#arch-overview-health-checking)来确定集群成员的健康状况。Envoy 如何将请求路由到集群成员由负载均衡策略确定。
|
||||
**Cluster**: 集群（cluster）是 Envoy 连接到的一组逻辑上相似的上游主机。Envoy 通过服务发现发现集群中的成员。Envoy 可以通过主动运行状况检查来确定集群成员的健康状况。Envoy 如何将请求路由到集群成员由负载均衡策略确定。
|
||||
|
||||
**Mesh**：一组互相协调以提供一致网络拓扑的主机。Envoy mesh 是指一组 Envoy 代理，它们构成了由多种不同服务和应用程序平台组成的分布式系统的消息传递基础。
|
||||
|
||||
|
|
@ -32,7 +32,7 @@
|
|||
|
||||
**Http Route Table**：HTTP 的路由规则，例如请求的域名，Path 符合什么规则，转发给哪个 Cluster。
|
||||
|
||||
**Health checking**：健康检查会与SDS服务发现配合使用。但是，即使使用其他服务发现方式，也有相应需要进行主动健康检查的情况。详见 [health checking](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/health_checking)。
|
||||
**Health checking**：健康检查会与SDS服务发现配合使用。但是，即使使用其他服务发现方式，也有相应需要进行主动健康检查的情况。
|
||||
|
||||
## xDS
|
||||
|
||||
|
|
@ -148,6 +148,5 @@ Cluster 的配置中至少包含以下信息：
|
|||
|
||||
## 参考
|
||||
|
||||
- [Terminology - www.envoyproxy.io](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/terminology)
|
||||
- [Part 1: Getting started with Envoy Proxy for microservices resilience](https://www.datawire.io/envoyproxy/getting-started-envoyproxy-microservices-resilience/)
|
||||
- [Envoy作为前端代理](envoy-front-proxy.md)
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ Istio架构分为控制平面和数据平面。
|
|||
|
||||
Istio使用Envoy代理的扩展版本，该代理是以C++开发的高性能代理，用于调解service mesh中所有服务的所有入站和出站流量。 Istio利用了Envoy的许多内置功能，例如动态服务发现，负载平衡，TLS终止，HTTP/2＆gRPC代理，断路器，运行状况检查，基于百分比的流量拆分分阶段上线，故障注入和丰富指标。
|
||||
|
||||
Envoy在kubernetes中作为pod的sidecar来部署。 这允许Istio将大量关于流量行为的信号作为属性提取出来，这些属性又可以在Mixer中用于执行策略决策，并发送给监控系统以提供有关整个mesh的行为的信息。 Sidecar代理模型还允许你将Istio功能添加到现有部署中，无需重新构建或重写代码。 更多信息参见[设计目标](https://istio.io/docs/concepts/what-is-istio/goals.html)。
|
||||
Envoy在kubernetes中作为pod的sidecar来部署。 这允许Istio将大量关于流量行为的信号作为属性提取出来，这些属性又可以在Mixer中用于执行策略决策，并发送给监控系统以提供有关整个mesh的行为的信息。 Sidecar代理模型还允许你将Istio功能添加到现有部署中，无需重新构建或重写代码。
|
||||
|
||||
## Mixer
|
||||
|
||||
|
|
@ -68,5 +68,5 @@ Istio-Auth提供强大的服务间和最终用户认证，使用相互TLS，内
|
|||
|
||||
## 参考
|
||||
|
||||
- [Istio：用于微服务的服务啮合层](http://www.infoq.com/cn/news/2017/05/istio?utm_source=news_about_opensource&utm_medium=link&utm_campaign=opensource)
|
||||
- [Istio：一个用于微服务间通信的服务网格开源项目](https://www.infoq.cn/article/2017/05/istio)
|
||||
- [Istio 是什么？](https://istio.io/zh/docs/concepts/what-is-istio/)
|
||||
|
|
|
|||
|
|
@ -156,7 +156,3 @@ kubectl apply -n default -f <(istioctl kube-inject -f manifests/istio/k8s-app-mo
|
|||
- 系统得进行 deployment 滚动更新
|
||||
|
||||
手动或者自动注入都使用同样的模板配置。自动注入会从 `istio-system` 命名空间下获取 `istio-inject` 的 ConfigMap。手动注入可以通过本地文件或者 Configmap 。
|
||||
|
||||
## 参考
|
||||
|
||||
- [Installing Istio Sidecar](https://istio.io/docs/setup/kubernetes/sidecar-injection.html)
|
||||
|
|
|
|||
|
|
@ -386,8 +386,6 @@ java -jar target/myproject-0.0.1-SNAPSHOT.jar
|
|||
|
||||
- [Spring官方网站](https://spring.io/)
|
||||
- [Spring core technologies - spring.io](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html)
|
||||
- [Spring Boot——开发新一代Spring Java应用](https://www.tianmaying.com/tutorial/spring-boot-overview)
|
||||
- [Spring MVC快速入门教程](https://www.tianmaying.com/tutorial/spring-mvc-quickstart)
|
||||
- [Spring Boot Reference Guide中文翻译 -《Spring Boot参考指南》](https://github.com/qibaoguang/Spring-Boot-Reference-Guide)
|
||||
- [使用 Spring Boot 快速构建 Spring 框架应用](https://www.ibm.com/developerworks/cn/java/j-lo-spring-boot/)
|
||||
- [maven3常用命令、java项目搭建、web项目搭建详细图解](http://blog.csdn.net/edward0830ly/article/details/8748986)
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
## 深入理解Istio Service Mesh中的Envoy Sidecar注入与流量劫持
|
||||
# 深入理解Istio Service Mesh中的Envoy Sidecar注入与流量劫持
|
||||
|
||||
**注意：本书中的 Service Mesh 章节已不再维护，请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。**
|
||||
|
||||
|
|
@ -269,7 +269,7 @@ ADD istio-iptables.sh /usr/local/bin/
|
|||
ENTRYPOINT ["/usr/local/bin/istio-iptables.sh"]
|
||||
```
|
||||
|
||||
我们看到 `istio-init` 容器的入口是 `/usr/local/bin/istio-iptables.sh` 脚本，再按图索骥看看这个脚本里到底写的什么，该脚本的位置在 Istio 源码仓库的 [tools/deb/istio-iptables.sh](https://github.com/istio/istio/blob/master/tools/deb/istio-iptables.sh)，一共 300 多行，就不贴在这里了。下面我们就来解析下这个启动脚本。
|
||||
我们看到 `istio-init` 容器的入口是 `/usr/local/bin/istio-iptables.sh` 脚本，再按图索骥看看这个脚本里到底写的什么，该脚本的位置在 Istio 源码仓库的 `tools/deb/istio-iptables.sh`，一共 300 多行，就不贴在这里了。下面我们就来解析下这个启动脚本。
|
||||
|
||||
### Init 容器启动入口
|
||||
|
||||
|
|
@ -400,10 +400,6 @@ Chain OUTPUT (policy ACCEPT 18M packets, 1916M bytes)
|
|||
|
||||
|
||||
|
||||
图片来自[常见 iptables 使用规则场景整理](https://www.aliang.org/Linux/iptables.html)
|
||||
|
||||
|
||||
|
||||
每条链中都可以添加多条规则，规则是按照顺序从前到后执行的。我们来看下规则的表头定义。
|
||||
|
||||
- **pkts**：处理过的匹配的报文数量
|
||||
|
|
|
|||
Loading…
Reference in New Issue