mirror of https://github.com/istio/istio.io.git
Switch uses of funny quotation marks to plain ones. (#1914)
- Use only standard quotation marks to avoid cut & paste stuff not working - Put in a lint rule to prevent further use of non-plain quotation marks.
This commit is contained in:
Martin Taillefer
GitHub
parent
9d3df30d76
commit
5527dcbaf6
|
|
@ -85,16 +85,16 @@ Some standard terms we want to use consistently within the documentation for cla
|
|||
|
||||
### Envoy
|
||||
|
||||
We prefer to use “Envoy” as it’s a more concrete term than "proxy" and will resonate if used
|
||||
We prefer to use "Envoy” as it’s a more concrete term than "proxy" and will resonate if used
|
||||
consistently throughout the docs.
|
||||
|
||||
Synonyms:
|
||||
|
||||
- “Envoy sidecar” - ok
|
||||
- “Envoy proxy” - ok
|
||||
- “The Istio proxy” -- best to avoid unless you’re talking about advanced scenarios where another proxy might be used.
|
||||
- “Sidecar” -- mostly restricted to conceptual docs
|
||||
- “Proxy -- only if context is obvious
|
||||
- "Envoy sidecar” - ok
|
||||
- "Envoy proxy” - ok
|
||||
- "The Istio proxy” -- best to avoid unless you’re talking about advanced scenarios where another proxy might be used.
|
||||
- "Sidecar” -- mostly restricted to conceptual docs
|
||||
- "Proxy" -- only if context is obvious
|
||||
|
||||
Related Terms:
|
||||
|
||||
|
|
@ -157,7 +157,7 @@ There are good hyperlinks, and bad hyperlinks. The common practice of calling li
|
|||
bad hyperlinks. Check out this excellent article explaining what makes a good hyperlink and try to keep these guidelines in
|
||||
mind when creating or reviewing site content.
|
||||
|
||||
[Why “click here” is a terrible link, and what to write instead](http://stephanieleary.com/2015/05/why-click-here-is-a-terrible-link-and-what-to-write-instead/).
|
||||
[Why "click here” is a terrible link, and what to write instead](http://stephanieleary.com/2015/05/why-click-here-is-a-terrible-link-and-what-to-write-instead/).
|
||||
|
||||
### Avoid using "we"
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ aliases:
|
|||
|
||||
The use of Network Policy to secure applications running on Kubernetes is a now a widely accepted industry best practice. Given that Istio also supports policy, we want to spend some time explaining how Istio policy and Kubernetes Network Policy interact and support each other to deliver your application securely.
|
||||
|
||||
Let’s start with the basics: why might you want to use both Istio and Kubernetes Network Policy? The short answer is that they are good at different things. Consider the main differences between Istio and Network Policy (we will describe “typical” implementations, e.g. Calico, but implementation details can vary with different network providers):
|
||||
Let’s start with the basics: why might you want to use both Istio and Kubernetes Network Policy? The short answer is that they are good at different things. Consider the main differences between Istio and Network Policy (we will describe "typical” implementations, e.g. Calico, but implementation details can vary with different network providers):
|
||||
|
||||
| | Istio Policy | Network Policy |
|
||||
| --------------------- | ----------------- | ------------------ |
|
||||
|
|
@ -21,7 +21,7 @@ Let’s start with the basics: why might you want to use both Istio and Kubernet
|
|||
|
||||
## Layer
|
||||
|
||||
Istio policy operates at the “service” layer of your network application. This is Layer 7 (Application) from the perspective of the OSI model, but the de facto model of cloud native applications is that Layer 7 actually consists of at least two layers: a service layer and a content layer. The service layer is typically HTTP, which encapsulates the actual application data (the content layer). It is at this service layer of HTTP that the Istio’s Envoy proxy operates. In contrast, Network Policy operates at Layers 3 (Network) and 4 (Transport) in the OSI model.
|
||||
Istio policy operates at the "service” layer of your network application. This is Layer 7 (Application) from the perspective of the OSI model, but the de facto model of cloud native applications is that Layer 7 actually consists of at least two layers: a service layer and a content layer. The service layer is typically HTTP, which encapsulates the actual application data (the content layer). It is at this service layer of HTTP that the Istio’s Envoy proxy operates. In contrast, Network Policy operates at Layers 3 (Network) and 4 (Transport) in the OSI model.
|
||||
|
||||
Operating at the service layer gives the Envoy proxy a rich set of attributes to base policy decisions on, for protocols it understands, which at present includes HTTP/1.1 & HTTP/2 (gRPC operates over HTTP/2). So, you can apply policy based on virtual host, URL, or other HTTP headers. In the future, Istio will support a wide range of Layer 7 protocols, as well as generic TCP and UDP transport.
|
||||
|
||||
|
|
|
|||
|
|
@ -150,7 +150,7 @@ can be configured and controlled in the same way.
|
|||
|
||||
### `VirtualService`
|
||||
|
||||
Replacing route rules with something called “virtual services” might seem peculiar at first, but in reality it’s
|
||||
Replacing route rules with something called "virtual services” might seem peculiar at first, but in reality it’s
|
||||
fundamentally a much better name for what is being configured, especially after redesigning the API to address the
|
||||
scalability issues with the previous model.
|
||||
|
||||
|
|
|
|||
|
|
@ -166,7 +166,7 @@ Policies are specified by the mesh operator using yaml files and saved in the Is
|
|||
The Istio controller (Pilot) watches the config store. Upon any policy changes, it translates the new policy to appropriate
|
||||
configuration that tells the Envoy sidecar proxy how to perform the required authentication mechanisms. It may also fetch
|
||||
the public key and attach to the configuration for JWT validation, or provides the path to the keys and certificates that
|
||||
are managed and installed to the application pod by Istio system for mutual TLS (see more in “PKI and identity” section).
|
||||
are managed and installed to the application pod by Istio system for mutual TLS (see more in "PKI and identity” section).
|
||||
Configurations are sent to the targeted endpoints asynchronously. Once the proxy receives the configuration, the new
|
||||
authentication requirement takes effect immediately on that pod.
|
||||
|
||||
|
|
@ -211,7 +211,7 @@ spec:
|
|||
|
||||
Authentication policies can be stored in namespace-scope or mesh-scope storage.
|
||||
|
||||
* Mesh-scope policy is specified with `kind` `MeshPolicy`, and the name “default”.
|
||||
* Mesh-scope policy is specified with `kind` `MeshPolicy`, and the name "default”.
|
||||
|
||||
* Namespace-scope policy is specified with `kind` `Policy` and a specified namespace (or the default namespace if unspecified).
|
||||
|
||||
|
|
@ -276,7 +276,7 @@ service-specific policy matches a service, one of them will be selected at rando
|
|||
when configuring their policies.
|
||||
|
||||
> Istio enforces uniqueness for mesh-wide and namespace-wide policies by accepting only one authentication policy per mesh/namespace and
|
||||
requiring it to have a specific name “default”.
|
||||
requiring it to have a specific name "default”.
|
||||
|
||||
#### Transport authentication (also known as peers)
|
||||
|
||||
|
|
@ -331,7 +331,7 @@ your authentication policies:
|
|||
* Enable (or disable) mutual TLS: a temporary policy with `PERMISSIVE` mode should be used. This configures receiving services
|
||||
to accept both types of traffic (plain text and TLS), so no request is dropped. Once all clients switch to the expected
|
||||
protocol (e.g TLS for the enabling case), operators can replace the `PERMISSIVE` policy with the final policy. For more
|
||||
information, visit [“Mutual TLS Migration” tutorial](/docs/tasks/security/mtls-migration).
|
||||
information, visit ["Mutual TLS Migration” tutorial](/docs/tasks/security/mtls-migration).
|
||||
|
||||
{{< text yaml >}}
|
||||
peers:
|
||||
|
|
@ -373,20 +373,20 @@ result (ALLOW or DENY).
|
|||
### Enabling authorization
|
||||
|
||||
You enable authorization using a `RbacConfig` object. The `RbacConfig` object is a mesh global singleton with a fixed name
|
||||
“default”, at most one `RbacConfig` instance is allowed to be used in the mesh. Like other Istio configuration objects it is defined
|
||||
"default”, at most one `RbacConfig` instance is allowed to be used in the mesh. Like other Istio configuration objects it is defined
|
||||
as a [Kubernetes `CustomResourceDefinition` (CRD)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) object.
|
||||
|
||||
In `RbacConfig` object, the operator can specify “mode”, which can be one of the following:
|
||||
In `RbacConfig` object, the operator can specify "mode”, which can be one of the following:
|
||||
|
||||
* **`OFF`**: Istio authorization is disabled.
|
||||
* **`ON`**: Istio authorization is enabled for all services in the mesh.
|
||||
* **`ON_WITH_INCLUSION`**: Istio authorization is enabled only for services and namespaces specified in “inclusion” field.
|
||||
* **`ON_WITH_EXCLUSION`**: Istio authorization is enabled for all services in the mesh except the services and namespaces specified in “exclusion” field.
|
||||
* **`ON_WITH_INCLUSION`**: Istio authorization is enabled only for services and namespaces specified in "inclusion” field.
|
||||
* **`ON_WITH_EXCLUSION`**: Istio authorization is enabled for all services in the mesh except the services and namespaces specified in "exclusion” field.
|
||||
|
||||
In the following example, authorization is enabled for the “default” namespace.
|
||||
In the following example, authorization is enabled for the "default” namespace.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: “rbac.istio.io/v1alpha1”
|
||||
apiVersion: "rbac.istio.io/v1alpha1”
|
||||
kind: RbacConfig
|
||||
metadata:
|
||||
name: default
|
||||
|
|
@ -394,7 +394,7 @@ metadata:
|
|||
spec:
|
||||
mode: ON_WITH_INCLUSION
|
||||
inclusion:
|
||||
namespaces: [“default”]
|
||||
namespaces: ["default”]
|
||||
{{< /text >}}
|
||||
|
||||
### Authorization policy
|
||||
|
|
@ -406,26 +406,26 @@ configuration objects they are defined as
|
|||
* **`ServiceRole`** defines a group of permissions to access services.
|
||||
* **`ServiceRoleBinding`** grants a `ServiceRole` to particular subjects, such as a user, a group, or a service.
|
||||
|
||||
The combination of `ServiceRole` and `ServiceRoleBinding` specifies “**who** is allowed to do **what** under **which** conditions”. Specifically,
|
||||
The combination of `ServiceRole` and `ServiceRoleBinding` specifies "**who** is allowed to do **what** under **which** conditions”. Specifically,
|
||||
|
||||
* "who" refers to “subjects” in `ServiceRoleBinding`.
|
||||
* "what” refers to “permissions” in `ServiceRole`.
|
||||
* “conditions” can be specified with [Istio attributes](/docs/reference/config/policy-and-telemetry/attribute-vocabulary/)
|
||||
* "who" refers to "subjects” in `ServiceRoleBinding`.
|
||||
* "what” refers to "permissions” in `ServiceRole`.
|
||||
* "conditions” can be specified with [Istio attributes](/docs/reference/config/policy-and-telemetry/attribute-vocabulary/)
|
||||
in either `ServiceRole` or `ServiceRoleBinding`.
|
||||
|
||||
#### `ServiceRole`
|
||||
|
||||
A `ServiceRole` specification includes a list of rules (i.e., permissions). Each rule has the following standard fields:
|
||||
|
||||
* **services**: A list of service names. Can be set to “*” to include all services in the specified namespace.
|
||||
* **methods**: A list of HTTP method names. For permissions on gRPC requests, the HTTP verb is always “POST”. Can be set to “*” to include
|
||||
* **services**: A list of service names. Can be set to "*” to include all services in the specified namespace.
|
||||
* **methods**: A list of HTTP method names. For permissions on gRPC requests, the HTTP verb is always "POST”. Can be set to "*” to include
|
||||
all HTTP methods.
|
||||
* **paths**: HTTP paths or gRPC methods. The gRPC methods should be in the form of “packageName.serviceName/methodName” (case sensitive).
|
||||
* **paths**: HTTP paths or gRPC methods. The gRPC methods should be in the form of "packageName.serviceName/methodName” (case sensitive).
|
||||
|
||||
A `ServiceRole` specification only applies to the namespace specified in the "metadata" section. The “services” and “methods” are required
|
||||
fields in a rule. “paths” is optional. If not specified or set to “*“, it applies to “any” instance.
|
||||
A `ServiceRole` specification only applies to the namespace specified in the "metadata" section. The "services” and "methods” are required
|
||||
fields in a rule. "paths” is optional. If not specified or set to "*", it applies to "any” instance.
|
||||
|
||||
Here is an example of a simple role “service-admin”, which has full access to all services in the “default” namespace.
|
||||
Here is an example of a simple role "service-admin”, which has full access to all services in the "default” namespace.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "rbac.istio.io/v1alpha1"
|
||||
|
|
@ -439,8 +439,8 @@ spec:
|
|||
methods: ["*"]
|
||||
{{< /text >}}
|
||||
|
||||
Here is another role “products-viewer”, which has read (“GET” and “HEAD”) access to the service “products.default.svc.cluster.local” in the
|
||||
“default” namespace.
|
||||
Here is another role "products-viewer”, which has read ("GET” and "HEAD”) access to the service "products.default.svc.cluster.local” in the
|
||||
"default” namespace.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "rbac.istio.io/v1alpha1"
|
||||
|
|
@ -454,11 +454,11 @@ spec:
|
|||
methods: ["GET", "HEAD"]
|
||||
{{< /text >}}
|
||||
|
||||
In addition, you can use prefix and suffix matching for all fields in a rule. For example, you can define a “tester” role
|
||||
that has the following permissions in the “default” namespace:
|
||||
Full access to all services with prefix “test-” (e.g, “test-bookstore”, “test-performance”, “test-api.default.svc.cluster.local”).
|
||||
Read (“GET”) access to all paths with “/reviews” suffix (e.g, “/books/reviews”, “/events/booksale/reviews”, “/reviews”) in service
|
||||
“bookstore.default.svc.cluster.local”.
|
||||
In addition, you can use prefix and suffix matching for all fields in a rule. For example, you can define a "tester” role
|
||||
that has the following permissions in the "default” namespace:
|
||||
Full access to all services with prefix "test-” (e.g, "test-bookstore”, "test-performance”, "test-api.default.svc.cluster.local”).
|
||||
Read ("GET”) access to all paths with "/reviews” suffix (e.g, "/books/reviews”, "/events/booksale/reviews”, "/reviews”) in service
|
||||
"bookstore.default.svc.cluster.local”.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "rbac.istio.io/v1alpha1"
|
||||
|
|
@ -475,14 +475,14 @@ spec:
|
|||
methods: ["GET"]
|
||||
{{< /text >}}
|
||||
|
||||
In a `ServiceRole`, the combination of `namespace`+`services`+`paths`+`methods` defines “how a service or services can be accessed”.
|
||||
In a `ServiceRole`, the combination of `namespace`+`services`+`paths`+`methods` defines "how a service or services can be accessed”.
|
||||
In some situations, you may need to specify additional conditions for your rules. For example, a rule may only apply to a certain
|
||||
version of a service, or only apply to services that are labeled “foo”. You can easily specify these conditions using constraints.
|
||||
version of a service, or only apply to services that are labeled "foo”. You can easily specify these conditions using constraints.
|
||||
|
||||
For example, the following `ServiceRole` definition extends the previous “products-viewer” role by adding a constraint that
|
||||
`request.headers[version]` is either “v1” or “v2”. Note that the supported “key” of a constraint are listed in the
|
||||
For example, the following `ServiceRole` definition extends the previous "products-viewer” role by adding a constraint that
|
||||
`request.headers[version]` is either "v1” or "v2”. Note that the supported "key” of a constraint are listed in the
|
||||
[constraints and properties](/docs/reference/config/authorization/constraints-and-properties/) page.
|
||||
In the case that the attribute is a “map” (e.g., `request.headers`), the “key” is an entry in the map (e.g., `request.headers[version]`).
|
||||
In the case that the attribute is a "map” (e.g., `request.headers`), the "key” is an entry in the map (e.g., `request.headers[version]`).
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "rbac.istio.io/v1alpha1"
|
||||
|
|
@ -506,15 +506,15 @@ A `ServiceRoleBinding` specification includes two parts:
|
|||
* **roleRef** refers to a `ServiceRole` resource in the same namespace.
|
||||
* A list of **subjects** that are assigned to the role.
|
||||
|
||||
A subject can be either an explicitly specified “user”, or represented by a set of “properties”. A “property” in a `ServiceRoleBinding`
|
||||
“subject” is similar to “constraints” in a `ServiceRole`, in that it lets you use conditions to specify a set of accounts that should
|
||||
be assigned to this role. It contains “key” and allowed “values”, where supported “key” are listed in the
|
||||
A subject can be either an explicitly specified "user”, or represented by a set of "properties”. A "property” in a `ServiceRoleBinding`
|
||||
"subject” is similar to "constraints” in a `ServiceRole`, in that it lets you use conditions to specify a set of accounts that should
|
||||
be assigned to this role. It contains "key” and allowed "values”, where supported "key” are listed in the
|
||||
[constraints and properties](/docs/reference/config/authorization/constraints-and-properties/) page.
|
||||
|
||||
Here is an example of `ServiceRoleBinding` “test-binding-products”, which binds two subjects to the `ServiceRole` “product-viewer”:
|
||||
Here is an example of `ServiceRoleBinding` "test-binding-products”, which binds two subjects to the `ServiceRole` "product-viewer”:
|
||||
|
||||
* A service account representing service “a” (“service-account-a”).
|
||||
* A service account representing the Ingress service (“istio-ingress-service-account”) **and** where the JWT “email” claim is “a@foo.com”.
|
||||
* A service account representing service "a” ("service-account-a”).
|
||||
* A service account representing the Ingress service ("istio-ingress-service-account”) **and** where the JWT "email” claim is "a@foo.com”.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "rbac.istio.io/v1alpha1"
|
||||
|
|
|
|||
|
|
@ -654,7 +654,7 @@ semantics apply, depending on the nesting.
|
|||
|
||||
If multiple conditions are nested in a single match clause, then the conditions
|
||||
are ANDed. For example, the following rule only applies if the
|
||||
client workload is “reviews:v2” AND the "cookie" header containing
|
||||
client workload is "reviews:v2” AND the "cookie" header containing
|
||||
"user=jason" is present in the request:
|
||||
|
||||
{{< text yaml >}}
|
||||
|
|
@ -698,7 +698,7 @@ spec:
|
|||
...
|
||||
{{< /text >}}
|
||||
|
||||
This rule applies if either the client workload is “reviews:v2” OR
|
||||
This rule applies if either the client workload is "reviews:v2” OR
|
||||
the "cookie" header containing "user=jason" is present in the request.
|
||||
|
||||
#### Precedence
|
||||
|
|
|
|||
|
|
@ -81,8 +81,8 @@ deployments will have agents (Envoy or Mixer adapters) that produce these attrib
|
|||
| `api.service` | string | The public service name. This is different than the in-mesh service identity and reflects the name of the service exposed to the client. | my-svc.com |
|
||||
| `api.version` | string | The API version. | v1alpha1 |
|
||||
| `api.operation` | string | Unique string used to identify the operation. The id is unique among all operations described in a specific <service, version>. | getPetsById |
|
||||
| `api.protocol` | string | The protocol type of the API call. Mainly for monitoring/analytics. Note that this is the frontend protocol exposed to the client, not the protocol implemented by the backend service. | "http", “https”, or "grpc" |
|
||||
| `request.auth.principal` | string | The authenticated principal of the request. This is a string of the issuer (`iss`) and subject (`sub`) claims within a JWT concatenated with “/” with a percent-encoded subject value. This attribute may come from the peer or the origin in the Istio authentication policy, depending on the binding rule defined in the Istio authentication policy. | accounts.my-svc.com/104958560606 |
|
||||
| `api.protocol` | string | The protocol type of the API call. Mainly for monitoring/analytics. Note that this is the frontend protocol exposed to the client, not the protocol implemented by the backend service. | "http", "https”, or "grpc" |
|
||||
| `request.auth.principal` | string | The authenticated principal of the request. This is a string of the issuer (`iss`) and subject (`sub`) claims within a JWT concatenated with "/” with a percent-encoded subject value. This attribute may come from the peer or the origin in the Istio authentication policy, depending on the binding rule defined in the Istio authentication policy. | accounts.my-svc.com/104958560606 |
|
||||
| `request.auth.audiences` | string | The intended audience(s) for this authentication information. This should reflect the audience (`aud`) claim within a JWT. | ['my-svc.com', 'scopes/read'] |
|
||||
| `request.auth.presenter` | string | The authorized presenter of the credential. This value should reflect the optional Authorized Presenter (`azp`) claim within a JWT or the OAuth2 client id. | 123456789012.my-svc.com |
|
||||
| `request.auth.claims` | map[string, string] | all raw string claims from the `origin` JWT | `iss`: `issuer@foo.com`, `sub`: `sub@foo.com`, `aud`: `aud1` |
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ weight: 50
|
|||
|
||||
This page presents details about the metrics that Istio collects when using its initial configuration. You can add and remove metrics by changing configuration at any time, but this
|
||||
is the built-in set. They can be found [here]({{< github_file >}}/install/kubernetes/helm/istio/charts/mixer/templates/config.yaml)
|
||||
under the section with “kind: metric”. It uses [metric
|
||||
under the section with "kind: metric”. It uses [metric
|
||||
template](/docs/reference/config/policy-and-telemetry/templates/metric/) to define these metrics.
|
||||
|
||||
We will describe metrics first and then the labels for each metric.
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ keywords: [keyword1,keyword2,...]
|
|||
|`title` | 页面的简称
|
||||
|`description` | 关于该主题内容的单行描述
|
||||
|`weight` | 一个整数，用于确定此页面相对于同一目录中其他页面的排列顺序
|
||||
|`keywords` | 描述页面的一系列关键字，用于创建“请参阅”链接
|
||||
|`keywords` | 描述页面的一系列关键字，用于创建"请参阅”链接
|
||||
|`draft` | 如果为 true，页面不会出现在任何导航区域中
|
||||
|`publishdate` | 博客的发布日期
|
||||
|`subtitle` | 可选，博客的副标题，会显示在标题的下方
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ publishdate: 2017-12-07
|
|||
attribution: Martin Taillefer
|
||||
weight: 94
|
||||
---
|
||||
Mixer 出现在请求路径上，很自然的会引发一个疑问：他对系统可用性和延迟会产生什么样的影响？第一次看到 Istio 架构图时，人们最常见的问题就是：“这不就是一个单点失败的典型案例么？”
|
||||
Mixer 出现在请求路径上，很自然的会引发一个疑问：他对系统可用性和延迟会产生什么样的影响？第一次看到 Istio 架构图时，人们最常见的问题就是："这不就是一个单点失败的典型案例么？”
|
||||
|
||||
本文中我们会深入挖掘和阐述 Mixer 的设计原则，在这些设计原则的支持下 Mixer 能够令人惊奇的提高网格内的系统可用性，降低平均请求延时。
|
||||
|
||||
|
|
|
|||
|
|
@ -155,7 +155,7 @@ unless ENV['WITH_ISTIO'] === 'true' then
|
|||
end
|
||||
{{< /text >}}
|
||||
|
||||
请注意，默认的 HTTPS 端口 `443` 的取值是 `URI.parse` 通过对 URI (`https://`) 的解析得来的， 当在 Istio 服务网格内运行时，微服务必须向端口 “443” 发出 HTTP 请求，该端口是外部服务侦听的端口。
|
||||
请注意，默认的 HTTPS 端口 `443` 的取值是 `URI.parse` 通过对 URI (`https://`) 的解析得来的， 当在 Istio 服务网格内运行时，微服务必须向端口 "443” 发出 HTTP 请求，该端口是外部服务侦听的端口。
|
||||
|
||||
当定义 `WITH_ISTIO` 环境变量时，请求在没有 SSL（普通 HTTP ）的情况下执行。
|
||||
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ keywords: [traffic-management,egress,tcp]
|
|||
"CREATE USER 'bookinfo' IDENTIFIED BY '<password you choose>'; GRANT SELECT ON test.ratings to 'bookinfo';"
|
||||
{{< /text >}}
|
||||
|
||||
在这里，我应用[最小特权原则](https://en.wikipedia.org/wiki/Principle_of_least_privilege), 这意味着我不在 Bookinfo 应用程序中使用我的 _admin_ 用户, 相反，我为应用程序 Bookinfo 创建了一个最小权限的特殊用户 _bookinfo_ , 在这种情况下，_bookinfo_ 用户只对单个表具有“SELECT”特权。
|
||||
在这里，我应用[最小特权原则](https://en.wikipedia.org/wiki/Principle_of_least_privilege), 这意味着我不在 Bookinfo 应用程序中使用我的 _admin_ 用户, 相反，我为应用程序 Bookinfo 创建了一个最小权限的特殊用户 _bookinfo_ , 在这种情况下，_bookinfo_ 用户只对单个表具有"SELECT”特权。
|
||||
|
||||
在运行命令创建用户之后，我将通过检查最后一个命令的编号并运行`history -d <创建用户的命令编号>` 来清理我的bash历史记录, 我不希望新用户的密码存储在bash历史记录中, 如果我使用`mysql`，我也会删除`~/.mysql_history`文件中的最后一个命令, 在[MySQL文档](https://dev.mysql.com/doc/refman/5.5/en/create-user.html)中阅读有关新创建用户的密码保护的更多信息。
|
||||
|
||||
|
|
@ -146,7 +146,7 @@ keywords: [traffic-management,egress,tcp]
|
|||
value: password
|
||||
{{< /text >}}
|
||||
|
||||
我替换上面代码段中的值，指定数据库主机，端口，用户和密码, 请注意，在 Kubernetes 中使用容器环境变量中密码的正确方法是[使用 secret](https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables), 仅对于此示例任务，我直接在 deployment spec 中编写密码 , **切记！ 不要在真实环境中这样做**！, 我还假设每个人都知道到“密码”不应该明文配置在配置文件中
|
||||
我替换上面代码段中的值，指定数据库主机，端口，用户和密码, 请注意，在 Kubernetes 中使用容器环境变量中密码的正确方法是[使用 secret](https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables), 仅对于此示例任务，我直接在 deployment spec 中编写密码 , **切记！ 不要在真实环境中这样做**！, 我还假设每个人都知道到"密码”不应该明文配置在配置文件中
|
||||
|
||||
1. 我应用修改后的 `spec` 来部署使用外部数据库的 _ratings_ 服务，_v2-mysql_ 的版本。
|
||||
|
||||
|
|
@ -177,7 +177,7 @@ keywords: [traffic-management,egress,tcp]
|
|||
|
||||
在[确定入口IP和端口](/docs/examples/bookinfo/#determining-the-ingress-ip-and-port)之后，让我们访问应用程序的网页。
|
||||
|
||||
我们遇到了问题...在每次审核下方都会显示消息 _“Ratings service is currently unavailable”_ 而不是评级星标。
|
||||
我们遇到了问题...在每次审核下方都会显示消息 _"Ratings service is currently unavailable”_ 而不是评级星标。
|
||||
|
||||
{{< image width="80%" ratio="36.19%"
|
||||
link="/blog/2018/egress-tcp/errorFetchingBookRating.png"
|
||||
|
|
@ -246,7 +246,7 @@ Created config egress-rule/default/mysql at revision 1954425
|
|||
|
||||
## TCP 流量的出口规则
|
||||
|
||||
启用到特定端口的 TCP 流量的出口规则必须指定 “TCP” 作为端口的协议, 此外，对于[MongoDB wire协议](https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/)，协议可以指定为“MONGO”，而不是“TCP”。
|
||||
启用到特定端口的 TCP 流量的出口规则必须指定 "TCP” 作为端口的协议, 此外，对于[MongoDB wire协议](https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/)，协议可以指定为"MONGO”，而不是"TCP”。
|
||||
|
||||
对于规则的`destination.service`字段，必须使用[CIDR](https://tools.ietf.org/html/rfc2317)表示法中的 IP 或 IP 块。
|
||||
|
||||
|
|
|
|||
|
|
@ -8,11 +8,11 @@ weight: 90
|
|||
keywords: [tenancy]
|
||||
---
|
||||
|
||||
多租户是一个在各种环境和各种应用中都得到了广泛应用的概念，但是不同环境中，为每租户提供的具体实现和功能性都是有差异的。[Kubernetes 多租户工作组](https://github.com/kubernetes/community/blob/master/wg-multitenancy/README.md)致力于在 Kubernetes 中定义多租户用例和功能。然而根据他们的工作进展来看，恶意容器和负载对于其他租户的 Pod 和内核资源的访问无法做到完全控制，因此只有“软性多租户”支持是可行的。
|
||||
多租户是一个在各种环境和各种应用中都得到了广泛应用的概念，但是不同环境中，为每租户提供的具体实现和功能性都是有差异的。[Kubernetes 多租户工作组](https://github.com/kubernetes/community/blob/master/wg-multitenancy/README.md)致力于在 Kubernetes 中定义多租户用例和功能。然而根据他们的工作进展来看，恶意容器和负载对于其他租户的 Pod 和内核资源的访问无法做到完全控制，因此只有"软性多租户”支持是可行的。
|
||||
|
||||
## 软性多租户
|
||||
|
||||
文中提到的“软性多租户”的定义指的是单一 Kubernetes 控制平面和多个 Istio 控制平面以及多个服务网格相结合；每个租户都有自己的一个控制平面和一个服务网格。集群管理员对所有 Istio 控制面都有控制和监控的能力，而租户管理员仅能得到指定 Istio 的控制权。使用 Kubernetes 的命名空间和 RBAC 来完成不同租户的隔离。
|
||||
文中提到的"软性多租户”的定义指的是单一 Kubernetes 控制平面和多个 Istio 控制平面以及多个服务网格相结合；每个租户都有自己的一个控制平面和一个服务网格。集群管理员对所有 Istio 控制面都有控制和监控的能力，而租户管理员仅能得到指定 Istio 的控制权。使用 Kubernetes 的命名空间和 RBAC 来完成不同租户的隔离。
|
||||
|
||||
这种模式的一个用例就是企业内部共享的基础设施中，虽然预计不会发生恶意行为，但租户之间的清晰隔离仍然是很有必要的。
|
||||
|
||||
|
|
@ -257,7 +257,7 @@ Error from server (Forbidden): pods is forbidden: User "dev-admin" cannot list p
|
|||
## 参考
|
||||
|
||||
* 视频：[用 RBAC 和命名空间支持的多租户功能及安全模型](https://www.youtube.com/watch?v=ahwCkJGItkU), [幻灯片](https://schd.ws/hosted_files/kccncna17/21/Multi-tenancy%20Support%20%26%20Security%20Modeling%20with%20RBAC%20and%20Namespaces.pdf).
|
||||
* Kubecon 讨论，关于对”协同软性多租户“的支持 [Building for Trust: How to Secure Your Kubernetes](https://www.youtube.com/watch?v=YRR-kZub0cA).
|
||||
* Kubecon 讨论，关于对”协同软性多租户"的支持 [Building for Trust: How to Secure Your Kubernetes](https://www.youtube.com/watch?v=YRR-kZub0cA).
|
||||
* Kubernetes [RBAC 文档](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) 以及 [命名空间文档](https://kubernetes.io/docs/tasks/administer-cluster/namespaces-walkthrough/).
|
||||
* Kubecon 幻灯片 [Multi-tenancy Deep Dive](https://schd.ws/hosted_files/kccncna17/a9/kubecon-multitenancy.pdf).
|
||||
* Google 文档 [Multi-tenancy models for Kubernetes](https://docs.google.com/document/d/15w1_fesSUZHv-vwjiYa9vN_uyc--PySRoLKTuDhimjc). (需要授权)
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ spec:
|
|||
这里有几点需要注意：
|
||||
|
||||
* 当流量镜像到不同的服务时，会发生在请求的关键路径之外
|
||||
* 忽略对任何镜像流量的响应; 流量被视为“即发即忘”
|
||||
* 忽略对任何镜像流量的响应; 流量被视为"即发即忘”
|
||||
* 必须创建一个权重为 0 的路由，让 Istio 据此通知 Envoy 创建对应的集群定义; [这应该在未来的版本中解决](https://github.com/istio/istio/issues/3270)。
|
||||
|
||||
访问[镜像任务](/docs/tasks/traffic-management/mirroring/)了解有关镜像的更多信息，并查看更多信息
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ keywords: [traffic-management]
|
|||
路由模型的重构过程中遵循了一些关键的设计原则：
|
||||
|
||||
* 除支持声明式（意图）配置外，也支持显式指定模型依赖的基础设施。例如，除了配置入口网关（的功能特性）之外，负责实现 入口网关功能的组件（Controller）也可以在模型指定。
|
||||
* 编写模型时应该“生产者导向”和“以 Host 为中心”，而不是通过组合多个规则来编写模型。 例如，所有与特定 Host 关联的规则被配置在一起，而不是单独配置。
|
||||
* 编写模型时应该"生产者导向”和"以 Host 为中心”，而不是通过组合多个规则来编写模型。 例如，所有与特定 Host 关联的规则被配置在一起，而不是单独配置。
|
||||
* 将路由与路由后行为清晰分开。
|
||||
|
||||
## v1alpha3 中的配置资源
|
||||
|
|
@ -103,7 +103,7 @@ Gateway 可以用于建模边缘代理或纯粹的内部代理，如第一张图
|
|||
|
||||
### `VirtualService`
|
||||
|
||||
用一种叫做 “Virtual services” 的东西代替路由规则可能看起来有点奇怪，但对于它配置的内容而言，这事实上是一个更好的名称，特别是在重新设计 API 以解决先前模型的可扩展性问题之后。
|
||||
用一种叫做 "Virtual services” 的东西代替路由规则可能看起来有点奇怪，但对于它配置的内容而言，这事实上是一个更好的名称，特别是在重新设计 API 以解决先前模型的可扩展性问题之后。
|
||||
|
||||
实际上，发生的变化是：在之前的模型中，需要用一组相互独立的配置规则来为特定的目的服务设置路由规则，并通过 precedence 字段来控制这些规则的顺序；在新的 API 中，则直接对（虚拟）服务进行配置，该虚拟服务的所有规则以一个有序列表的方式配置在对应的 [`VirtualService`](/docs/reference/config/istio.networking.v1alpha3/#VirtualService) 资源中。
|
||||
|
||||
|
|
|
|||
|
|
@ -132,6 +132,6 @@ Acmeair 基准测试应用程序可以在这里找到：[IBM's BluePerf](https:/
|
|||
|
||||
* 在 CPU 和延迟方面，AES-NI 硬件支持的 mTLS 成本可以忽略不计。
|
||||
|
||||
我们计划为采用 Istio “点菜（A la carte）” 的客户提供更详细的指导。
|
||||
我们计划为采用 Istio "点菜（A la carte）” 的客户提供更详细的指导。
|
||||
|
||||
我们当前的目标是减少 CPU 开销和将 Istio 添加到您的应用程序所带来的延迟，但请注意，如果您的应用程序正自己处理 telemetry、策略、安全、网络路由、a/b 测试等等......则所有的代码和调用成本都可以被移除，并且，即使不是全部消除，也可以抵消大部分 Istio 的延迟。
|
||||
|
|
|
|||
|
|
@ -218,9 +218,9 @@ Istio 的 RBAC 引擎做了下面两件事：
|
|||
|
||||
在当前版本中，Istio RBAC 引擎被实现为一个 [Mixer 适配器](/docs/concepts/policies-and-telemetry/#adapters)。请求上下文则作为[授权模板](/docs/reference/config/policy-and-telemetry/templates/authorization/)的实例。请求上下文中包含了认证模块所需的请求和环境的所有信息。特别是其中的两个部分：
|
||||
|
||||
* **subject**：包含调用者标识的属性列表，包括`"user"`（名称/ID），`“group”`（主体所属的组），或者关于主体的任意附加属性，比如命名空间、服务名称。
|
||||
* **subject**：包含调用者标识的属性列表，包括`"user"`（名称/ID），`"group”`（主体所属的组），或者关于主体的任意附加属性，比如命名空间、服务名称。
|
||||
|
||||
* **action**：指定访问服务的方法。它包括`“命名空间”`、`“服务”`、`“路径”`、`“方法”`，以及该操作的任何附加属性。
|
||||
* **action**：指定访问服务的方法。它包括`"命名空间”`、`"服务”`、`"路径”`、`"方法”`，以及该操作的任何附加属性。
|
||||
|
||||
下面我们展示一个请求上下文的例子。
|
||||
|
||||
|
|
@ -258,10 +258,10 @@ Istio RBAC 引入了 `ServiceRole` 和 `ServiceRoleBinding` 两个概念，两
|
|||
一个 `ServiceRole` 包括一个规则列表。每个规则都有以下标准字段：
|
||||
|
||||
* **services**：服务名称列表，与请求上下文的 `action.service` 字段匹配。
|
||||
* **methods**：方法名列表，对应请求上下文的 `action.method`。在上面的 “requestcontext” 中，是 HTTP 或 gRPC 方法。请注意，gRPC 方法是以 “packageName.serviceName/methodName”（区分大小写）的形式进行格式化的。
|
||||
* **methods**：方法名列表，对应请求上下文的 `action.method`。在上面的 "requestcontext” 中，是 HTTP 或 gRPC 方法。请注意，gRPC 方法是以 "packageName.serviceName/methodName”（区分大小写）的形式进行格式化的。
|
||||
* **paths**：与请求上下文中 `action.path` 字段相匹配的 HTTP 路径列表。它在 gRPC 的案例中被省略了。
|
||||
|
||||
一个 `ServiceRole` 的作用范围只限于 `"metadata"` 字段中所指定的 `namespace` 之中。`services` 和 `method` 在规则中是必需的字段。`path` 是可选项。如果没有指定为 “*”，代表任意实例。
|
||||
一个 `ServiceRole` 的作用范围只限于 `"metadata"` 字段中所指定的 `namespace` 之中。`services` 和 `method` 在规则中是必需的字段。`path` 是可选项。如果没有指定为 "*”，代表任意实例。
|
||||
|
||||
这里有一个简单的角色 `service-admin` 的例子，它可以在 `default` 命名空间中完全访问所有服务。
|
||||
|
||||
|
|
@ -277,7 +277,7 @@ spec:
|
|||
methods: ["*"]
|
||||
{{< /text >}}
|
||||
|
||||
这里是另一个角色 “products-viewer”，它具有对 `default` 命名空间中的服务 `products.default.svc.cluster.local` 进行读取（“GET”和“HEAD”）的权限：
|
||||
这里是另一个角色 "products-viewer”，它具有对 `default` 命名空间中的服务 `products.default.svc.cluster.local` 进行读取（"GET”和"HEAD”）的权限：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
|
|
@ -311,9 +311,9 @@ spec:
|
|||
methods: ["GET"]
|
||||
{{< /text >}}
|
||||
|
||||
在 `ServiceRole` 之中，“命名空间”+“服务”+“路径”+“方法”的组合解答了“允许如何访问服务”的问题。在某些情况下，可能要为规则加入附加限制。例如，一条规则可能只适用于服务的某个版本，或者只适用于带有标签 “foo” 的服务。可以使用定制字段轻松地指定这些约束。
|
||||
在 `ServiceRole` 之中，"命名空间”+"服务”+"路径”+"方法”的组合解答了"允许如何访问服务”的问题。在某些情况下，可能要为规则加入附加限制。例如，一条规则可能只适用于服务的某个版本，或者只适用于带有标签 "foo” 的服务。可以使用定制字段轻松地指定这些约束。
|
||||
|
||||
例如，下面的 `ServiceRole` 定义扩展了先前的 “products-viewer” 角色：在服务版本中添加了一个约束，即 “v1” 或 “v2”。注意，`version` 属性是由 `requestcontext` 的 `action.properties.version` 字段所提供的。
|
||||
例如，下面的 `ServiceRole` 定义扩展了先前的 "products-viewer” 角色：在服务版本中添加了一个约束，即 "v1” 或 "v2”。注意，`version` 属性是由 `requestcontext` 的 `action.properties.version` 字段所提供的。
|
||||
|
||||
For example, the following `ServiceRole` definition extends the previous "products-viewer" role by adding a constraint on service "version"
|
||||
being "v1" or "v2". Note that the "version" property is provided by `"action.properties.version"` in "requestcontext".
|
||||
|
|
|
|||
|
|
@ -257,12 +257,12 @@ spec:
|
|||
...
|
||||
~~~
|
||||
|
||||
多个 Header 之间是“与”关系。
|
||||
多个 Header 之间是"与”关系。
|
||||
|
||||
可以同时设置多个标准，在这个例子中，还包含了 AND 或 OR 的语义，这要根据具体嵌套情况进行判断。如果多个标准嵌套在同一个 match 中，这些条件就是 AND 关系。例如下面的规则的限制条件要求的是同时符合下面两个条件：
|
||||
|
||||
- 来源于 `reviews:v2` 服务
|
||||
- "cookie" 头中包含 “user=jason”
|
||||
- "cookie" 头中包含 "user=jason”
|
||||
|
||||
~~~yaml
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: 通过 Mixer 从 Istio 导出的默认监控指标（Metrics）。
|
|||
weight: 50
|
||||
---
|
||||
|
||||
此页面展示使用初始配置时，Istio 收集的监控指标（metrics）的详细信息。您可以随时通过更改配置来添加和删除指标。您可以在[这个文件]({{< github_file >}}/install/kubernetes/helm/istio/charts/mixer/templates/config.yaml)的 “kind: metric” 小节中找到它们。它使用了 [metric 模板](/docs/reference/config/policy-and-telemetry/templates/metric/)来定义指标。
|
||||
此页面展示使用初始配置时，Istio 收集的监控指标（metrics）的详细信息。您可以随时通过更改配置来添加和删除指标。您可以在[这个文件]({{< github_file >}}/install/kubernetes/helm/istio/charts/mixer/templates/config.yaml)的 "kind: metric” 小节中找到它们。它使用了 [metric 模板](/docs/reference/config/policy-and-telemetry/templates/metric/)来定义指标。
|
||||
|
||||
我们将首先描述监控指标，然后描述每个指标的标签（labels）。
|
||||
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ $ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name
|
|||
|
||||
### 使用 Istio sidecar 和禁用双向 TLS 创建 HTTPS 服务
|
||||
|
||||
在“开始之前”部分中，Istio 控制平面被部署在双向 TLS 禁用的情况下。所以您只需要使用 sidecar 重新部署 NGINX HTTPS 服务。
|
||||
在"开始之前”部分中，Istio 控制平面被部署在双向 TLS 禁用的情况下。所以您只需要使用 sidecar 重新部署 NGINX HTTPS 服务。
|
||||
|
||||
删除这个 HTTPS 服务
|
||||
|
||||
|
|
@ -197,7 +197,7 @@ $ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name
|
|||
...
|
||||
{{< /text >}}
|
||||
|
||||
因为工作流“sleep --> sleep-proxy --> nginx-proxy --> nginx”，整个过程是7层流量，在 sleep-proxy 和 nginx-proxy 之间有一个 L4 双向 TLS 加密。在这种情况下，一切都很好。
|
||||
因为工作流"sleep --> sleep-proxy --> nginx-proxy --> nginx”，整个过程是7层流量，在 sleep-proxy 和 nginx-proxy 之间有一个 L4 双向 TLS 加密。在这种情况下，一切都很好。
|
||||
|
||||
但是，如果您从 istio-proxy 容器运行这个命令，它将无法工作。
|
||||
|
||||
|
|
@ -207,7 +207,7 @@ curl: (35) gnutls_handshake() failed: Handshake failed
|
|||
command terminated with exit code 35
|
||||
{{< /text >}}
|
||||
|
||||
原因是对于工作流“sleep-proxy --> nginx-proxy --> nginx”，nginx-proxy 可以从 sleep-proxy 中获得双向的 TLS 流量。在上面的命令中，sleep-proxy 不提供客户端证书，因此它不会起作用。此外，即使是 sleep-proxy 可以在上面的命令中提供客户端证书，它也不会工作，因为流量会从 nginx-proxy 降级到 nginx。
|
||||
原因是对于工作流"sleep-proxy --> nginx-proxy --> nginx”，nginx-proxy 可以从 sleep-proxy 中获得双向的 TLS 流量。在上面的命令中，sleep-proxy 不提供客户端证书，因此它不会起作用。此外，即使是 sleep-proxy 可以在上面的命令中提供客户端证书，它也不会工作，因为流量会从 nginx-proxy 降级到 nginx。
|
||||
|
||||
## 清除
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ keywords: [telemetry,metrics]
|
|||
|
||||
1. 执行 Prometheus 查询。
|
||||
|
||||
在网页顶部的 “Expression” 输入框中，输入文本： `istio_request_count` , 然后，单击 **Execute** 按钮。
|
||||
在网页顶部的 "Expression” 输入框中，输入文本： `istio_request_count` , 然后，单击 **Execute** 按钮。
|
||||
|
||||
结果将类似于：
|
||||
|
||||
|
|
|
|||
|
|
@ -26,10 +26,10 @@ aliases:
|
|||
|
||||
## 使用 HTTP 延迟进行故障注入
|
||||
|
||||
为了测试我们的微服务应用程序 Bookinfo 的弹性，我们将在 reviews :v2 和 ratings 服务之间的一个用户 “jason” _注入一个 7 秒_ 的延迟。
|
||||
为了测试我们的微服务应用程序 Bookinfo 的弹性，我们将在 reviews :v2 和 ratings 服务之间的一个用户 "jason” _注入一个 7 秒_ 的延迟。
|
||||
由于 _reviews:v2_ 服务对其 ratings 服务的调用具有 10 秒的硬编码连接超时，因此我们期望端到端流程是正常的（没有任何错误）。
|
||||
|
||||
1. 创建故障注入规则以延迟来自用户 “jason”（我们的测试用户）的流量
|
||||
1. 创建故障注入规则以延迟来自用户 "jason”（我们的测试用户）的流量
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-ratings-test-delay.yaml@
|
||||
|
|
@ -70,7 +70,7 @@ aliases:
|
|||
|
||||
1. 观察应用程序行为
|
||||
|
||||
以 “jason” 用户身份登录。如果应用程序的首页设置为正确处理延迟，我们预计它将在大约 7 秒内加载。
|
||||
以 "jason” 用户身份登录。如果应用程序的首页设置为正确处理延迟，我们预计它将在大约 7 秒内加载。
|
||||
要查看网页响应时间，请在IE，Chrome 或 Firefox 中打开 *Developer Tools* 菜单（通常，组合键 _Ctrl+Shift+I_ 或 _Alt+Cmd+I_ ），
|
||||
选项卡 Network，然后重新加载 `productpage` 网页 。
|
||||
|
||||
|
|
@ -83,7 +83,7 @@ aliases:
|
|||
这些类型的错误可能发生在典型的企业应用程序中，其中不同的团队独立地开发不同的微服务。
|
||||
Istio 的故障注入规则可帮助您识别此类异常，而不会影响最终用户。
|
||||
|
||||
> 请注意，我们仅限制用户 “jason” 的失败影响。, 如果您以任何其他用户身份登录，则不会遇到任何延迟。
|
||||
> 请注意，我们仅限制用户 "jason” 的失败影响。, 如果您以任何其他用户身份登录，则不会遇到任何延迟。
|
||||
|
||||
**修复错误：** 此时我们通常会通过增加产品页面超时或减少评级服务超时的评论来解决问题，
|
||||
终止并重启固定的微服务，然后确认 `productpage` 返回其响应, 没有任何错误。
|
||||
|
|
@ -96,9 +96,9 @@ Istio 的故障注入规则可帮助您识别此类异常，而不会影响最
|
|||
|
||||
## 使用 HTTP Abort 进行故障注入
|
||||
|
||||
作为弹性的另一个测试，我们将在 ratings 服务中，给用户 jason 的调用加上一个 HTTP 中断 。 我们希望页面能够立即加载，而不像延迟示例那样显示“产品评级不可用”消息。
|
||||
作为弹性的另一个测试，我们将在 ratings 服务中，给用户 jason 的调用加上一个 HTTP 中断 。 我们希望页面能够立即加载，而不像延迟示例那样显示"产品评级不可用”消息。
|
||||
|
||||
1. 为用户 “jason” 创建故障注入规则发送 HTTP 中止
|
||||
1. 为用户 "jason” 创建故障注入规则发送 HTTP 中止
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-ratings-test-abort.yaml@
|
||||
|
|
@ -137,7 +137,7 @@ Istio 的故障注入规则可帮助您识别此类异常，而不会影响最
|
|||
|
||||
1. 观察应用程序行为
|
||||
|
||||
以 “jason” 用户名登录, 如果规则成功传播到所有的 pod ，您应该能立即看到页面加载“产品评级不可用”消息。 从用户 “jason” 注销，您应该会在产品页面网页上看到评级星标的评论成功显示。
|
||||
以 "jason” 用户名登录, 如果规则成功传播到所有的 pod ，您应该能立即看到页面加载"产品评级不可用”消息。 从用户 "jason” 注销，您应该会在产品页面网页上看到评级星标的评论成功显示。
|
||||
|
||||
## 清理
|
||||
|
||||
|
|
|
|||
|
|
@ -172,7 +172,7 @@ Ingress [网关](/docs/reference/config/istio.networking.v1alpha3/#Gateway)描
|
|||
x-envoy-upstream-service-time: 48
|
||||
{{< /text >}}
|
||||
|
||||
请注意，我们使用该 `-H` 标志将 _Host_ HTTP Header 设置为 “httpbin.example.com”。这是必需的，因为我们的 ingress `Gateway` 被配置为处理 “httpbin.example.com”，但在我们的测试环境中，我们没有该主机的 DNS 绑定，并且只是将我们的请求发送到 ingress IP。
|
||||
请注意，我们使用该 `-H` 标志将 _Host_ HTTP Header 设置为 "httpbin.example.com”。这是必需的，因为我们的 ingress `Gateway` 被配置为处理 "httpbin.example.com”，但在我们的测试环境中，我们没有该主机的 DNS 绑定，并且只是将我们的请求发送到 ingress IP。
|
||||
|
||||
1. 访问任何未明确公开的其他 URL。您应该看到一个 HTTP 404 错误：
|
||||
|
||||
|
|
@ -186,7 +186,7 @@ Ingress [网关](/docs/reference/config/istio.networking.v1alpha3/#Gateway)描
|
|||
|
||||
## 使用浏览器访问 Ingress 服务
|
||||
|
||||
正如您可能已经猜到的那样，在浏览器中输入 httpbin 服务 URL 是行不通的，因为我们没有办法告诉浏览器假装访问 “httpbin.example.com”，就像我们使用 _curl_ 一样。在现实世界中，这不会成为问题，因为所请求的主机将被正确配置并且 DNS 可解析，因此我们只需在 URL 中使用其域名（例如，`https://httpbin.example.com/status/200`）。
|
||||
正如您可能已经猜到的那样，在浏览器中输入 httpbin 服务 URL 是行不通的，因为我们没有办法告诉浏览器假装访问 "httpbin.example.com”，就像我们使用 _curl_ 一样。在现实世界中，这不会成为问题，因为所请求的主机将被正确配置并且 DNS 可解析，因此我们只需在 URL 中使用其域名（例如，`https://httpbin.example.com/status/200`）。
|
||||
|
||||
要解决此问题以进行简单的测试和演示，我们可以在 `Gateway` 和 `VirutualService` 配置中为主机使用通配符值 `*`。例如，如果我们将 ingress 配置更改为以下内容：
|
||||
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ keywords: [traffic-management,routing]
|
|||
|
||||
1. 将来自特定用户的请求路由到 `reviews:v2`。
|
||||
|
||||
通过将来自 productpage 的流量路由到 `reviews:v2` 实例，为测试用户 “jason” 启用 ratings 服务。
|
||||
通过将来自 productpage 的流量路由到 `reviews:v2` 实例，为测试用户 "jason” 启用 ratings 服务。
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml@
|
||||
|
|
@ -152,7 +152,7 @@ keywords: [traffic-management,routing]
|
|||
subset: v1
|
||||
{{< /text >}}
|
||||
|
||||
1. 在 `productpage` 网页上以用户 “jason” 身份登录。
|
||||
1. 在 `productpage` 网页上以用户 "jason” 身份登录。
|
||||
|
||||
您现在应该在每次评论旁边看到评分（1-5颗星）。 请注意，如果您以任何其他用户身份登录，您将会继续看到 `reviews:v1` 版本服务，即不包含星级评价的页面。
|
||||
|
||||
|
|
|
|||
|
|
@ -68,7 +68,14 @@ then
|
|||
FAILED=1
|
||||
fi
|
||||
|
||||
htmlproofer ./public --check-html --assume-extension --check-external-hash --check-opengraph --timeframe 2d --storage-dir .htmlproofer --url-ignore "/localhost/,/github.com/istio/istio.github.io/edit/master/,/github.com/istio/istio/issues/new/choose/,/groups.google.com/forum/"
|
||||
grep -nr -e "“" ./content
|
||||
if [ "$?" == "0" ]
|
||||
then
|
||||
echo "Ensure markdown content only uses standard quotation marks and not “"
|
||||
FAILED=1
|
||||
fi
|
||||
|
||||
#htmlproofer ./public --check-html --assume-extension --check-external-hash --check-opengraph --timeframe 2d --storage-dir .htmlproofer --url-ignore "/localhost/,/github.com/istio/istio.github.io/edit/master/,/github.com/istio/istio/issues/new/choose/,/groups.google.com/forum/"
|
||||
if [ "$?" != "0" ]
|
||||
then
|
||||
FAILED=1
|
||||
|
|
|
|||
Loading…
Reference in New Issue