mirror of https://github.com/istio/istio.io.git
Move the Operations Guide to the documentation section. (#4099)
This commit is contained in:
Rigs Caballero
Martin Taillefer
parent
c86583e1f4
commit
bf4901af38
|
|
@ -306,7 +306,7 @@ This example shows there are many variables, based on whether the automatic side
|
|||
- default policy (Configured in the ConfigMap `istio-sidecar-injector`)
|
||||
- per-pod override annotation (`sidecar.istio.io/inject`)
|
||||
|
||||
The [injection status table](../../../help/ops/setup/injection/) shows a clear picture of the final injection status based on the value of the above variables.
|
||||
The [injection status table](/docs/ops/setup/injection/) shows a clear picture of the final injection status based on the value of the above variables.
|
||||
|
||||
## Traffic flow from application container to sidecar proxy
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
- Fixed virtual service host mismatch issue when adding a port.
|
||||
|
||||
- Added limited support for [merging multiple virtual service or destination rule definitions](/help/ops/traffic-management/deploy-guidelines/#multiple-virtual-services-and-destination-rules-for-the-same-host) for the same host.
|
||||
- Added limited support for [merging multiple virtual service or destination rule definitions](/docs/ops/traffic-management/deploy-guidelines/#multiple-virtual-services-and-destination-rules-for-the-same-host) for the same host.
|
||||
|
||||
- Allow [outlier](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/cluster/outlier_detection.proto) consecutive gateway failures when using HTTP.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
## Behavior changes
|
||||
|
||||
- [Validating webhook](/help/ops/setup/validation) is now mandatory. Disabling it may result in Pilot crashes.
|
||||
- [Validating webhook](/docs/ops/setup/validation) is now mandatory. Disabling it may result in Pilot crashes.
|
||||
|
||||
- [Service entry](/docs/reference/config/networking/v1alpha3/service-entry/) validation now rejects the wildcard hostname (`*`) when configuring DNS resolution. The API has never allowed this, however `ServiceEntry` was erroneously excluded from validation in the previous release. Use of wildcards as part of a hostname, e.g. `*.bar.com`, remains unchanged.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,10 +7,11 @@ sidebar_multicard: true
|
|||
icon: docs
|
||||
---
|
||||
|
||||
In addition, you might find these links interesting:
|
||||
In addition to the documentation, we provide the following resources:
|
||||
|
||||
- Check out our [Help](/help) section, which includes our [Operations Guide](/help/ops), our [FAQ](/help/faq), and our [glossary](/docs/reference/glossary).
|
||||
- [FAQ](/help/faq) section
|
||||
- [Glossary](/docs/reference/glossary).
|
||||
- [Release notes](/about/notes) for info on individual Istio releases.
|
||||
|
||||
- See our [release notes](/about/notes) for info on individual Istio releases.
|
||||
|
||||
- Nostalgic for days gone by? We keep an [archive of the earlier releases' documentation](https://archive.istio.io/).
|
||||
Are you looking for past versions of the documentation? We keep an
|
||||
[archive of the documentation for prior releases](https://archive.istio.io/).
|
||||
|
|
|
|||
|
|
@ -207,7 +207,7 @@ The geographic location typically represents a data center. Istio uses
|
|||
this information to prioritize load balancing pools to control
|
||||
the geographic location where requests are proxied.
|
||||
|
||||
For more information and instructions on how to enable this feature see the [operations guide](/help/ops/traffic-management/locality-load-balancing/).
|
||||
For more information and instructions on how to enable this feature see the [operations guide](/docs/ops/traffic-management/locality-load-balancing/).
|
||||
|
||||
## Handling failures
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,12 @@
|
|||
---
|
||||
title: Operations Guide
|
||||
description: Hints, tips, tricks about running an Istio mesh.
|
||||
weight: 5
|
||||
weight: 32
|
||||
aliases:
|
||||
- /troubleshooting.html
|
||||
- /troubleshooting/index.html
|
||||
- /help/troubleshooting/index.html
|
||||
- /help/ops
|
||||
- /ops
|
||||
icon: guide
|
||||
---
|
||||
|
|
@ -4,8 +4,8 @@ description: How to do low-level debugging of Istio components.
|
|||
weight: 25
|
||||
---
|
||||
|
||||
You can gain insights into what individual components are doing by inspecting their [logs](/help/ops/component-logging/)
|
||||
or peering inside via [introspection](/help/ops/controlz/). If that's insufficient, the steps below explain
|
||||
You can gain insights into what individual components are doing by inspecting their [logs](/docs/ops/component-logging/)
|
||||
or peering inside via [introspection](/docs/ops/controlz/). If that's insufficient, the steps below explain
|
||||
how to get under the hood.
|
||||
|
||||
## With `istioctl`
|
||||
|
|
@ -56,7 +56,7 @@ To retrieve information about endpoint configuration for the Envoy instance in a
|
|||
$ istioctl proxy-config endpoints <pod-name> [flags]
|
||||
{{< /text >}}
|
||||
|
||||
See [Debugging Envoy and Pilot](/help/ops/traffic-management/proxy-cmd/) for more advice on interpreting this information.
|
||||
See [Debugging Envoy and Pilot](/docs/ops/traffic-management/proxy-cmd/) for more advice on interpreting this information.
|
||||
|
||||
## With GDB
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ $ mixs server --log_output_level attributes=debug,adapters=warning
|
|||
{{< /text >}}
|
||||
|
||||
In addition to controlling the output level from the command-line, you can also control the output level of a running component
|
||||
by using its [ControlZ](/help/ops/controlz) interface.
|
||||
by using its [ControlZ](/docs/ops/controlz) interface.
|
||||
|
||||
## Controlling output
|
||||
|
||||
|
Before Width: | Height: | Size: 209 KiB After Width: | Height: | Size: 209 KiB |
|
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
title: Authorization Too Permissive
|
||||
description: Authorization is enabled, but requests make it through anyway.
|
||||
weight: 50
|
||||
---
|
||||
If authorization checks are enabled for a service and yet requests to the
|
||||
service aren't being blocked, then authorization was likely not enabled
|
||||
successfully. To verify, follow these steps:
|
||||
|
||||
1. Check the [enable authorization docs](/docs/concepts/security/#enabling-authorization)
|
||||
to correctly enable Istio authorization.
|
||||
|
||||
1. Avoid enabling authorization for Istio Control Planes Components, including
|
||||
Mixer, Pilot and Ingress. The Istio authorization features are designed for
|
||||
authorizing access to services in an Istio Mesh. Enabling the authorization
|
||||
features for the Istio Control Planes components can cause unexpected
|
||||
behavior.
|
||||
|
||||
1. In your Kubernetes environment, check deployments in all namespaces to make
|
||||
sure there is no legacy deployment left that can cause an error in Pilot.
|
||||
You can disable Pilot's authorization plug-in if there is an error pushing
|
||||
authorization policy to Envoy.
|
||||
|
||||
1. Visit [Debugging Authorization](/docs/ops/security/debugging-authorization/)
|
||||
to find out the exact cause.
|
||||
|
|
@ -21,4 +21,5 @@ for TCP services. Otherwise, Istio ignores the policies as if they didn't exist.
|
|||
`default` namespace (`metadata/namespace` line should be `default`). For non-Kubernetes environments, all `ServiceRoles` and `ServiceRoleBindings`
|
||||
for a mesh should be in the same namespace.
|
||||
|
||||
1. Follow the [Debugging Authorization docs](/help/ops/security/debugging-authorization/) to find out the exact cause.
|
||||
1. Visit [Debugging Authorization](/docs/ops/security/debugging-authorization/)
|
||||
to find out the exact cause.
|
||||
|
|
@ -5,7 +5,7 @@ weight: 20
|
|||
---
|
||||
|
||||
If you suspect that some of the keys and/or certificates used by Istio aren't correct, the
|
||||
first step is to ensure that [Citadel is healthy](/help/ops/security/repairing-citadel/).
|
||||
first step is to ensure that [Citadel is healthy](/docs/ops/security/repairing-citadel/).
|
||||
|
||||
You can then verify that Citadel is actually generating keys and certificates:
|
||||
|
||||
|
|
@ -4,8 +4,8 @@ description: What to do if mutual TLS authentication isn't working.
|
|||
weight: 30
|
||||
---
|
||||
|
||||
If you suspect problems with mutual TLS, first ensure that [Citadel is healthy](/help/ops/security/repairing-citadel/), and
|
||||
second ensure that [keys and certificates are being delivered](/help/ops/security/keys-and-certs/) to sidecars properly.
|
||||
If you suspect problems with mutual TLS, first ensure that [Citadel is healthy](/docs/ops/security/repairing-citadel/), and
|
||||
second ensure that [keys and certificates are being delivered](/docs/ops/security/keys-and-certs/) to sidecars properly.
|
||||
|
||||
If everything appears to be working so far, the next step is to verify that the right [authentication policy](/docs/tasks/security/authn-policy/) is applied and
|
||||
the right destination rules are in place.
|
||||
|
|
@ -4,7 +4,7 @@ description: Shows how to do health checking for Istio services.
|
|||
weight: 65
|
||||
aliases:
|
||||
- /docs/tasks/traffic-management/app-health-check/
|
||||
- /help/ops/security/health-checks-and-mtls/
|
||||
- /docs/ops/security/health-checks-and-mtls/
|
||||
keywords: [security,health-check]
|
||||
---
|
||||
|
||||
|
|
@ -31,7 +31,7 @@ keys are:
|
|||
|
||||
To see the Envoy settings for statistics data collection use
|
||||
`istioctl proxy-config bootstrap` and follow the
|
||||
[deep dive into Envoy configuration](/help/ops/traffic-management/proxy-cmd/#deep-dive-into-envoy-configuration).
|
||||
[deep dive into Envoy configuration](/docs/ops/traffic-management/proxy-cmd/#deep-dive-into-envoy-configuration).
|
||||
Envoy only collects statistical data on items matching the `inclusion_list` within
|
||||
the `stats_matcher` JSON element.
|
||||
|
||||
|
|
@ -133,7 +133,7 @@ spec:
|
|||
The downside of this kind of configuration is that other configuration (e.g., route rules) for any of the
|
||||
underlying microservices, will need to also be included in this single configuration file, instead of
|
||||
in separate resources associated with, and potentially owned by, the individual service teams.
|
||||
See [Route rules have no effect on ingress gateway requests](/help/ops/traffic-management/troubleshooting/#route-rules-have-no-effect-on-ingress-gateway-requests)
|
||||
See [Route rules have no effect on ingress gateway requests](/docs/ops/traffic-management/troubleshooting/#route-rules-have-no-effect-on-ingress-gateway-requests)
|
||||
for details.
|
||||
|
||||
To avoid this problem, it may be preferable to break up the configuration of `myapp.com` into several
|
||||
|
|
@ -61,7 +61,7 @@ cluster must satisfy the following requirements:
|
|||
- **`NET_ADMIN` capability**: If your cluster enforces pod security policies,
|
||||
pods must allow the `NET_ADMIN` capability. If you use the [Istio CNI Plugin](/docs/setup/kubernetes/additional-setup/cni/),
|
||||
this requirement no longer applies. To learn more about the `NET_ADMIN`
|
||||
capability, visit [Required Pod Capabilities](/help/ops/setup/required-pod-capabilities/).
|
||||
capability, visit [Required Pod Capabilities](/docs/ops/setup/required-pod-capabilities/).
|
||||
|
||||
## Ports used by Istio
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ The `httpbin` application serves as the backend service for this task.
|
|||
when calling the `httpbin` service:
|
||||
|
||||
{{< warning >}}
|
||||
If you installed/configured Istio with mutual TLS Authentication enabled, you must add a TLS traffic policy `mode: ISTIO_MUTUAL` to the `DestinationRule` before applying it. Otherwise requests will generate 503 errors as described [here](/help/ops/traffic-management/troubleshooting/#503-errors-after-setting-destination-rule).
|
||||
If you installed/configured Istio with mutual TLS authentication enabled, you must add a TLS traffic policy `mode: ISTIO_MUTUAL` to the `DestinationRule` before applying it. Otherwise requests will generate 503 errors as described [here](/docs/ops/traffic-management/troubleshooting/#503-errors-after-setting-destination-rule).
|
||||
{{< /warning >}}
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@ Let's see how you can configure a `Gateway` on port 80 for HTTP traffic.
|
|||
you can add the special value `mesh` to the list of `gateways`. Since the internal hostname for the
|
||||
service is probabaly different (e.g., `httpbin.default.svc.cluster.local`) from the external one,
|
||||
you will also need to add it to the `hosts` list. Refer to the
|
||||
[troubleshooting guide](/help/ops/traffic-management/troubleshooting/#route-rules-have-no-effect-on-ingress-gateway-requests)
|
||||
[troubleshooting guide](/docs/ops/traffic-management/troubleshooting/#route-rules-have-no-effect-on-ingress-gateway-requests)
|
||||
for more details.
|
||||
{{< /warning >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -127,7 +127,7 @@ In this step, you will change that behavior so that all traffic goes to `v1`.
|
|||
1. Create a default route rule to route all traffic to `v1` of the service:
|
||||
|
||||
{{< warning >}}
|
||||
If you installed/configured Istio with mutual TLS Authentication enabled, you must add a TLS traffic policy `mode: ISTIO_MUTUAL` to the `DestinationRule` before applying it. Otherwise requests will generate 503 errors as described [here](/help/ops/traffic-management/troubleshooting/#503-errors-after-setting-destination-rule).
|
||||
If you installed/configured Istio with mutual TLS authentication enabled, you must add a TLS traffic policy `mode: ISTIO_MUTUAL` to the `DestinationRule` before applying it. Otherwise requests will generate 503 errors as described [here](/docs/ops/traffic-management/troubleshooting/#503-errors-after-setting-destination-rule).
|
||||
{{< /warning >}}
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
|
|||
|
|
@ -3,5 +3,5 @@ title: Istio doesn't work - what do I do?
|
|||
weight: 90
|
||||
---
|
||||
|
||||
Check out the [operations guide](/help/ops/) for finding solutions and our
|
||||
Check out the [operations guide](/docs/ops/) for finding solutions and our
|
||||
[bug reporting](/about/bugs/) page for filing bugs.
|
||||
|
|
|
|||
|
|
@ -7,9 +7,11 @@ If mutual TLS is enabled, HTTP and TCP health checks from the kubelet will not w
|
|||
|
||||
As of Istio 1.1, we have several options to solve this issue.
|
||||
|
||||
1. Using probe rewrite to rewrite the liveness/readiness probe such that the probe request will be redirected to the workload directly. Please refer to [Probe Rewrite](/help/ops/setup/app-health-check/#probe-rewrite) for more information.
|
||||
1. Using probe rewrite to redirect liveness and readiness requests to the
|
||||
workload directly. Please refer to [Probe Rewrite](/docs/ops/setup/app-health-check/#probe-rewrite)
|
||||
for more information.
|
||||
|
||||
1. Using a separate port for health checks and enabling mutual TLS only on the regular service port. Please refer to [Health Checking of Istio Services](/help/ops/setup/app-health-check/#separate-port) for more information.
|
||||
1. Using a separate port for health checks and enabling mutual TLS only on the regular service port. Please refer to [Health Checking of Istio Services](/docs/ops/setup/app-health-check/#separate-port) for more information.
|
||||
|
||||
1. Using the [`PERMISSIVE` mode](/docs/tasks/security/mtls-migration) for Istio services so they can accept both HTTP and mutual TLS traffic. Please keep in mind that mutual TLS is not enforced since others can communicate with the service with HTTP traffic.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,20 +0,0 @@
|
|||
---
|
||||
title: Authorization Too Permissive
|
||||
description: Authorization is enabled, but requests make it through anyway.
|
||||
weight: 50
|
||||
---
|
||||
If authorization checks are enabled for a service and yet requests to the service aren't being blocked, then
|
||||
authorization was likely not enabled successfully. To verify, follow these steps:
|
||||
|
||||
1. Check the [enable authorization docs](/docs/concepts/security/#enabling-authorization) to correctly enable
|
||||
Istio authorization.
|
||||
|
||||
1. Avoid enabling authorization for Istio Control Planes Components, including Mixer, Pilot and Ingress.
|
||||
The Istio authorization features are designed for authorizing access to services in an Istio Mesh.
|
||||
Enabling the authorization features for the Istio Control Planes components can cause unexpected behavior.
|
||||
|
||||
1. In your Kubernetes environment, check deployments in all namespaces to make sure there is no legacy
|
||||
deployment left that can cause an error in Pilot. You can disable Pilot's authorization plug-in if
|
||||
there is an error pushing authorization policy to Envoy.
|
||||
|
||||
1. Follow the [Debugging Authorization docs](/help/ops/security/debugging-authorization/) to find out the exact cause.
|
||||
|
|
@ -309,7 +309,7 @@ spec:
|
|||
- 缺省策略（在 ConfigMap `istio-sidecar-injector` 中定义）
|
||||
- Pod 注解（`sidecar.istio.io/inject`）
|
||||
|
||||
[注入状态表](/zh/help/ops/setup/injection/)中，根据上面三个因素的不同，可以看到有不同的注入结果。
|
||||
[注入状态表](/zh/docs/ops/setup/injection/)中，根据上面三个因素的不同，可以看到有不同的注入结果。
|
||||
|
||||
## 从应用容器到 Sidecar 代理的通信
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
- 修复了增加一个端口时 Virtual service host 不匹配的问题。
|
||||
|
||||
- 添加了同一个主机内对 [合并多个 `VirtualService` 或 `DestinationRule` 定义](/zh/help/ops/traffic-management/deploy-guidelines/#在网关中配置多个-tls-主机)的有限支持。
|
||||
- 添加了同一个主机内对 [合并多个 `VirtualService` 或 `DestinationRule` 定义](/zh/docs/ops/traffic-management/deploy-guidelines/#在网关中配置多个-tls-主机)的有限支持。
|
||||
|
||||
- 允许在使用 HTTP 时，连续的出现 Gateway failures [outlier](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/cluster/outlier_detection.proto) 。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
## 行为变化
|
||||
|
||||
- [验证 Webhook](/zh/help/ops/setup/validation) 变成了必选项。如果禁用这一 Webhook 会导致 Pilot 崩溃。
|
||||
- [验证 Webhook](/zh/docs/ops/setup/validation) 变成了必选项。如果禁用这一 Webhook 会导致 Pilot 崩溃。
|
||||
|
||||
- [Service entry](/docs/reference/config/networking/v1alpha3/service-entry/) 校验，当配置了 DNS 解析的时候将拒绝不使用通配符主机名（`*`）。相关 API 从未允许这种行为，但在前一版本中，`ServiceEntry` 对象的验证过程错误的忽略了这一错误。
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ icon: docs
|
|||
|
||||
另外，您可能会发现这些有趣的链接：
|
||||
|
||||
- 查看我们的[帮助](/zh/help)文档，其中包括我们的[操作指南](/zh/help/ops)、[FAQ](/zh/help/faq)和[词汇表](/zh/docs/reference/glossary)。
|
||||
- 查看我们的[帮助](/zh/help)文档，其中包括我们的[操作指南](/zh/docs/ops)、[FAQ](/zh/help/faq)和[词汇表](/zh/docs/reference/glossary)。
|
||||
|
||||
- 有关各个 Istio 版本的信息，请参阅[发行说明](/zh/about/notes)。
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: 如何从底层调试 Istio 组件。
|
|||
weight: 25
|
||||
---
|
||||
|
||||
通过检查[日志](/zh/help/ops/component-logging/)或[内检](/zh/help/ops/controlz/)，可以深入了解各组件的工作情况。除此之外，下面的步骤将有助于更加深入了解相关情况。
|
||||
通过检查[日志](/zh/docs/ops/component-logging/)或[内检](/zh/docs/ops/controlz/)，可以深入了解各组件的工作情况。除此之外，下面的步骤将有助于更加深入了解相关情况。
|
||||
|
||||
## 使用 `istioctl`
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ $ istioctl proxy-config route <pod-name> [flags]
|
|||
$ istioctl proxy-config endpoints <pod-name> [flags]
|
||||
{{< /text >}}
|
||||
|
||||
点击[配置问题诊断](/zh/help/ops/traffic-management/proxy-cmd/)查看更多相关信息。
|
||||
点击[配置问题诊断](/zh/docs/ops/traffic-management/proxy-cmd/)查看更多相关信息。
|
||||
|
||||
## 使用 GDB
|
||||
|
||||
|
|
@ -70,4 +70,4 @@ $ istioctl proxy-config endpoints <pod-name> [flags]
|
|||
|
||||
Tcpdump 在 Sidecar 中不能工作 - 因为该容器不允许以 root 身份运行。但是由于同一 Pod 内会共享网络命名空间，因此 Pod 中的其他容器也能监听所有数据包。`iptables` 也能查看到 Pod 级别的相关配置。
|
||||
|
||||
Envoy 和应用程序之间的通信在地址 127.0.0.1 上进行，并且未进行加密。
|
||||
Envoy 和应用程序之间的通信在地址 127.0.0.1 上进行，并且未进行加密。
|
||||
|
|
@ -37,7 +37,7 @@ Pilot，Citadel 和 Galley 有不同的 scope ，具体参见[参考文档](/zh/
|
|||
$ mixs server --log_output_level attributes=debug,adapters=warning
|
||||
{{< /text >}}
|
||||
|
||||
除从命令行控制输出级别外，还可以使用其 [ControlZ](/zh/help/ops/controlz) 接口控制正在运行的组件的日志输出级别。
|
||||
除从命令行控制输出级别外，还可以使用其 [ControlZ](/zh/docs/ops/controlz) 接口控制正在运行的组件的日志输出级别。
|
||||
|
||||
## 控制输出
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ Mixer、Pilot 和 Galley 都实现了 ControlZ 功能。这些组件启动时将
|
|||
|
||||
下面是 ControlZ 界面的示例：
|
||||
|
||||
{{< image width="80%" link="ctrlz.png" caption="ControlZ 用户界面" >}}
|
||||
{{< image width="80%" link="/docs/ops/controlz/ctrlz.png" caption="ControlZ 用户界面" >}}
|
||||
|
||||
当启动组件时，可以通过命令行参数 `--ctrlz_port` 和 `--ctrlz_address` 指定特定的地址和端口来控制 ControlZ 暴露的地址。
|
||||
|
||||
|
|
@ -26,4 +26,4 @@ Mixer、Pilot 和 Galley 都实现了 ControlZ 功能。这些组件启动时将
|
|||
$ kubectl port-forward -n istio-system <podname> 9876:9876
|
||||
{{< /text >}}
|
||||
|
||||
这样把对应组件的 ControlZ 页面重定向到 `http://localhost:9876`，就可以进行访问了。
|
||||
这样把对应组件的 ControlZ 页面重定向到 `http://localhost:9876`，就可以进行访问了。
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: 授权太过宽松
|
||||
description: 已经启用了授权，但是无论如何请求还是会通过。
|
||||
description: 已经启用了授权，但是无论如何请求还是会通过。
|
||||
weight: 50
|
||||
---
|
||||
|
||||
|
|
@ -12,4 +12,4 @@ weight: 50
|
|||
|
||||
1. 在你的 Kubernetes 环境中，检查所有命名空间下的部署，确保没有可能导致 Istio 错误的遗留的部署。如果发现在向 Envoy 推送授权策略的时候发生错误，你可以禁用 Pilot 的授权插件。
|
||||
|
||||
1. 根据[调试授权文档](/help/ops/security/debugging-authorization/)找到确切的原因。
|
||||
1. 根据[调试授权文档](/docs/ops/security/debugging-authorization/)找到确切的原因。
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 授权过于严格
|
||||
title: 授权过于严格
|
||||
description: 启用了授权然后任何请求都无法到达服务。
|
||||
weight: 60
|
||||
---
|
||||
|
|
@ -17,4 +17,4 @@ weight: 60
|
|||
|
||||
1. 在 Kubernetes 环境，确保所有在一个 `ServiceRole` 对象下的服务都在和 `ServiceRole` 在同一个命名空间。例如，如果 `ServiceRole` 对象中的服务是 `a.default.svc.cluster.local`，`ServiceRole` 必须在 `default` 命名空间（`metadata/namespace` 这一行应该是 `default`）。对于非 Kubernetes 的环境，一个网格的所有 `ServiceRoles` 和 `ServiceRoleBindings` 都应该在相同的命名空间下。
|
||||
|
||||
1. 根据[调试授权文档](/zh/help/ops/security/debugging-authorization/)找到确切的原因。
|
||||
1. 根据[调试授权文档](/zh/docs/ops/security/debugging-authorization/)找到确切的原因。
|
||||
|
|
@ -5,7 +5,7 @@ weight: 20
|
|||
---
|
||||
|
||||
如果您怀疑 Istio 使用的某些密钥或证书不正确，那么
|
||||
第一步是确保 [Citadel 健康](/zh/help/ops/security/repairing-citadel/)。
|
||||
第一步是确保 [Citadel 健康](/zh/docs/ops/security/repairing-citadel/)。
|
||||
|
||||
然后，您可以验证 Citadel 是否实际生成密钥和证书：
|
||||
|
||||
|
|
@ -4,6 +4,6 @@ description: 如何处理 TLS 认证的失效问题。
|
|||
weight: 30
|
||||
---
|
||||
|
||||
如果观察到双向 TLS 的问题，首先要确认 [Citadel 的健康情况](/zh/help/ops/security/repairing-citadel/)，接下来要查看的是[密钥和证书](/help/ops/security/keys-and-certs/)是否已经被正确分发给 Sidecar.
|
||||
如果观察到双向 TLS 的问题，首先要确认 [Citadel 的健康情况](/zh/docs/ops/security/repairing-citadel/)，接下来要查看的是[密钥和证书](/docs/ops/security/keys-and-certs/)是否已经被正确分发给 Sidecar.
|
||||
|
||||
如果上述检查都正确无误，下一步就应该验证[认证策略](/zh/docs/tasks/security/authn-policy/)以及对应的目标规则是否正确应用。
|
||||
|
|
@ -25,8 +25,8 @@ $ kubectl exec -it $POD -c istio-proxy -- sh -c 'curl localhost:15000/stats'
|
|||
- `server`
|
||||
- `cluster.xds-grpc`
|
||||
|
||||
可以使用 `istioctl proxy-config bootstrap` 命令，并根据 [Envoy 配置深度解析](/zh/help/ops/traffic-management/proxy-cmd/#envoy-配置深度解析)中的介绍查看 Envoy 的统计配置。Envoy 要根据 `stats_matcher` JSON 元素中的 `inclusion_list` 进行判断，列表中的数据才会进行收集。
|
||||
可以使用 `istioctl proxy-config bootstrap` 命令，并根据 [Envoy 配置深度解析](/zh/docs/ops/traffic-management/proxy-cmd/#envoy-配置深度解析)中的介绍查看 Envoy 的统计配置。Envoy 要根据 `stats_matcher` JSON 元素中的 `inclusion_list` 进行判断，列表中的数据才会进行收集。
|
||||
|
||||
要配置 Envoy 来记录入站和出站的流量，可以在 Kubernetes 的 `Deployment` Pod 模板中加入注解 `sidecar.istio.io/statsInclusionPrefixes`。加入 `cluster.outbound`，就可以收集外发流量以及断路器的活动。加入 `listener` 就可以搜集入站流量信息。[fortio-deploy.yaml]({{< github_file>}}/samples/httpbin/sample-client/fortio-deploy.yaml) 中展示了 `cluster.outbound` 前缀的用法。
|
||||
|
||||
还可以覆盖 Envoy 的配置，使之收集更少的信息。例如使用 `sidecar.istio.io/statsInclusionPrefixes: cluster_manager,listener_manager` 注解收集最少信息。
|
||||
还可以覆盖 Envoy 的配置，使之收集更少的信息。例如使用 `sidecar.istio.io/statsInclusionPrefixes: cluster_manager,listener_manager` 注解收集最少信息。
|
||||
|
|
@ -125,7 +125,7 @@ spec:
|
|||
|
||||
这种配置的缺点是，任何底层微服务的其他配置（例如路由规则）也需要包含在该配置文件中，
|
||||
而不是包含在与之相关联并且可能由各个服务团队拥有的单独配置文件中。有关详细信息，
|
||||
在运维指南中的[“路由规则对 Ingress网关请求中无效”](/zh/help/ops/traffic-management/troubleshooting/#路由规则在-ingress-gateway-请求中无效)一节中提供了介绍。
|
||||
在运维指南中的[“路由规则对 Ingress网关请求中无效”](/zh/docs/ops/traffic-management/troubleshooting/#路由规则在-ingress-gateway-请求中无效)一节中提供了介绍。
|
||||
|
||||
为了避免这个问题，可能最好将 `myapp.com` 的配置分解为几个 `VirtualService` 片段，每个后端服务一个。例如：
|
||||
|
||||
|
|
@ -17,4 +17,4 @@ keywords: [kubernetes,sidecar,sidecar-injection]
|
|||
|
||||
* **Application UID**：**不要**使用 ID（UID）值为 **1337** 的用户来运行应用。
|
||||
|
||||
* **`NET_ADMIN` 功能**: 如果您的群集中实施了 Pod 安全策略，除非您使用 [Istio CNI 插件](/docs/setup/kubernetes/additional-setup/cni/)，您的 pod 必须具有`NET_ADMIN`功能。请参阅[必需的 Pod 功能](/help/ops/setup/required-pod-capabilities/)。
|
||||
* **`NET_ADMIN` 功能**: 如果您的群集中实施了 Pod 安全策略，除非您使用 [Istio CNI 插件](/docs/setup/kubernetes/additional-setup/cni/)，您的 pod 必须具有`NET_ADMIN`功能。请参阅[必需的 Pod 功能](/docs/ops/setup/required-pod-capabilities/)。
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ keywords: [traffic-management,circuit-breaking]
|
|||
1. 创建一个 [目标规则](/zh/docs/reference/config/istio.networking.v1alpha3/#destinationrule)，针对 `httpbin` 服务设置断路器：
|
||||
|
||||
{{< warning >}}
|
||||
如果您的 Istio 启用了双向 TLS 身份验证，则必须在应用之前将 TLS 流量策略 `mode：ISTIO_MUTUAL` 添加到 `DestinationRule`。否则请求将产生 503 错误，如[设置目标规则后出现 503 错误](/zh/help/ops/traffic-management/troubleshooting/#设置目标规则后出现-503-错误)所述。
|
||||
如果您的 Istio 启用了双向 TLS 身份验证，则必须在应用之前将 TLS 流量策略 `mode：ISTIO_MUTUAL` 添加到 `DestinationRule`。否则请求将产生 503 错误，如[设置目标规则后出现 503 错误](/zh/docs/ops/traffic-management/troubleshooting/#设置目标规则后出现-503-错误)所述。
|
||||
{{< /warning >}}
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
|
|||
|
|
@ -121,7 +121,7 @@ keywords: [traffic-management,mirroring]
|
|||
1. 创建一个默认路由规则，将所有流量路由到服务的 `v1` ：
|
||||
|
||||
{{< warning >}}
|
||||
如果为 Istio 启用了双向 TLS 认证，在应用前必须将 TLS 流量策略 `mode: ISTIO_MUTUAL` 添加到 `DestinationRule`。否则，请求将发生 503 错误，如[设置目标规则后出现 503 错误](/zh/help/ops/traffic-management/troubleshooting/#设置目标规则后出现-503-错误)所述。
|
||||
如果为 Istio 启用了双向 TLS 认证，在应用前必须将 TLS 流量策略 `mode: ISTIO_MUTUAL` 添加到 `DestinationRule`。否则，请求将发生 503 错误，如[设置目标规则后出现 503 错误](/zh/docs/ops/traffic-management/troubleshooting/#设置目标规则后出现-503-错误)所述。
|
||||
{{< /warning >}}
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
|
|||
|
|
@ -3,4 +3,4 @@ title: Istio 不工作了应该怎么做？
|
|||
weight: 90
|
||||
---
|
||||
|
||||
查看 [操作指南](/help/ops/) 寻找解决方案或者 [错误报告](/about/bugs/) 页面去提交错误。
|
||||
查看 [操作指南](/docs/ops/) 寻找解决方案或者 [错误报告](/about/bugs/) 页面去提交错误。
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ weight: 50
|
|||
，因此当这个模式打开时他们可以接受 http 和双向 TLS 流量。这可以解决健康检查问题。
|
||||
请记住，双向 TLS 没有强制执行，因为其他服务可以使用 http 流量与该服务进行通信。
|
||||
|
||||
您可以使用单独的端口进行健康检查，并只在常规服务端口上启用双向 TLS。请参阅 [Istio 服务的健康检查](/zh/help/ops/setup/app-health-check/)了解更多信息。
|
||||
您可以使用单独的端口进行健康检查，并只在常规服务端口上启用双向 TLS。请参阅 [Istio 服务的健康检查](/zh/docs/ops/setup/app-health-check/)了解更多信息。
|
||||
|
||||
由于存在新功能的风险，我们默认情况下不会启用上述功能。未来的推出计划将在 [GitHub 问题](https://github.com/istio/istio/issues/10357)上进行跟踪。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue