fix broken links
Jimmy Song
parent
a275b0a1f1
commit
78fc767318
|
|
@ -185,7 +185,7 @@ spec:
|
|||
|
||||
- 客户端向 `http://foo.example.com` 发出请求。
|
||||
- DNS 将该名称解析为网关地址。
|
||||
- 反向代理在 `Listener` 上接收请求，并使用 [`Host` 头](https://tools.ietf.org/html/rfc7230#section-5.4) 来匹配 `HTTPRoute`。
|
||||
- 反向代理在 `Listener` 上接收请求，并使用 `Host` 头 来匹配 `HTTPRoute`。
|
||||
- 可选地，反向代理可以根据 `HTTPRoute` 的匹配规则执行请求头和 / 或路径匹配。
|
||||
- 可选地，反向代理可以根据 `HTTPRoute` 的过滤规则修改请求，即添加 / 删除头。
|
||||
- 最后，反向代理可以根据 `HTTPRoute` 的 `forwardTo` 规则，将请求转发到集群中的一个或多个对象，即 `Service`。
|
||||
|
|
|
|||
|
|
@ -176,7 +176,7 @@ foo.bar.com --| |-> foo.bar.com s1:80
|
|||
bar.foo.com --| |-> bar.foo.com s2:80
|
||||
```
|
||||
|
||||
下面这个 ingress 说明基于 [Host header](https://tools.ietf.org/html/rfc7230#section-5.4) 的后端 loadbalancer 的路由请求：
|
||||
下面这个 ingress 说明基于 [Host header](https://datatracker.ietf.org/doc/html/rfc7230#section-5.4) 的后端 loadbalancer 的路由请求：
|
||||
|
||||
```yaml
|
||||
apiVersion: extensions/v1beta1
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ Service Catalog 安装 servicecatalog.k8s.ioAPI 并提供以以下 Kubernetes
|
|||
Service Catalog 支持这些认证方法：
|
||||
|
||||
- Basic (username/password)
|
||||
- [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750)
|
||||
- OAuth 2.0 Bearer Token
|
||||
|
||||
## 用法
|
||||
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ ip-masq-agent 用户配置 iptables 规则将 Pod 的 IP 地址隐藏在集群 n
|
|||
|
||||
本地链路地址是仅能在主机连接的网段或广播域内进行有效通信的网络地址。IPv4 的链路本地地址在 CIDR 表示法定义的地址块是 169.254.0.0/16。
|
||||
|
||||
Ip-masq-agent 在将流量发送到集群 node 节点的 IP 和 Cluster IP 范围之外的目的地时，会配置 iptables 规则来处理伪装的 node/pod IP 地址。这基本上将 pod 的 IP 地址隐藏在了集群 node 节点的 IP 地址后面。在某些环境中，到 “外部” 地址的流量必须来自已知的机器地址。例如，在 Google Cloud 中，到互联网的任何流量必须来自虚拟机的 IP。当使用容器时，如在GKE中，Pod IP 将被拒绝作为出口。为了避免这种情况，我们必须将 Pod IP 隐藏在 VM 自己的 IP 地址之后——通常被称为 “伪装”。默认情况下，配置代理将 [RFC 1918](https://tools.ietf.org/html/rfc1918)指定的三个专用 IP 范围视为非伪装 [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing)。范围包括 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。默认情况下，代理还将本地链路（169.254.0.0/16）视为非伪装 CIDR。代理配置为每隔60秒从 */etc/config/ip-masq-agent* 位置重新加载其配置，这也是可配置的。
|
||||
Ip-masq-agent 在将流量发送到集群 node 节点的 IP 和 Cluster IP 范围之外的目的地时，会配置 iptables 规则来处理伪装的 node/pod IP 地址。这基本上将 pod 的 IP 地址隐藏在了集群 node 节点的 IP 地址后面。在某些环境中，到 “外部” 地址的流量必须来自已知的机器地址。例如，在 Google Cloud 中，到互联网的任何流量必须来自虚拟机的 IP。当使用容器时，如在GKE中，Pod IP 将被拒绝作为出口。为了避免这种情况，我们必须将 Pod IP 隐藏在 VM 自己的 IP 地址之后——通常被称为 “伪装”。默认情况下，配置代理将指定的三个专用 IP 范围视为非伪装 [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing)。范围包括 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。默认情况下，代理还将本地链路（169.254.0.0/16）视为非伪装 CIDR。代理配置为每隔60秒从 */etc/config/ip-masq-agent* 位置重新加载其配置，这也是可配置的。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ EOF
|
|||
2017/03/21 06:48:17 [INFO] encoded CSR
|
||||
```
|
||||
|
||||
此命令生成两个文件；它生成包含 PEM 编码的 [pkcs #10](https://tools.ietf.org/html/rfc2986) 认证请求的 `server.csr`，以及包含仍然要创建的证书的 PEM 编码密钥的 `server-key.pem`。
|
||||
此命令生成两个文件；它生成包含 PEM 编码的 [pkcs #10](https://datatracker.ietf.org/doc/html/rfc2986) 认证请求的 `server.csr`，以及包含仍然要创建的证书的 PEM 编码密钥的 `server-key.pem`。
|
||||
|
||||
### 创建证书签名请求对象以发送到 Kubernetes API
|
||||
|
||||
|
|
|
|||
|
|
@ -240,7 +240,7 @@ curl --header "Content-Type: application/json-patch+json" \
|
|||
http://k8s-master:8080/api/v1/nodes/k8s-node-1/status
|
||||
```
|
||||
|
||||
**注意：** 在前面的请求中，`~1` 是 patch 路径中 `/` 字符的编码。JSON-Patch 中的操作路径值被解释为 JSON-Pointer。更多详细信息请参阅 [IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3)。
|
||||
**注意：** 在前面的请求中，`~1` 是 patch 路径中 `/` 字符的编码。JSON-Patch 中的操作路径值被解释为 JSON-Pointer。更多详细信息请参阅 [IETF RFC 6901, section 3](https://datatracker.ietf.org/doc/html/rfc6901#section-3)。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
|
|||
Loading…
Reference in New Issue