diff --git a/.circleci/config.yml b/.circleci/config.yml index 6a7e921feb..026e62cd17 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -11,7 +11,7 @@ jobs: - run: name: Generating Site - command: scripts/gen_site.sh "" -no_minify + command: scripts/gen_site.sh "" -no_minify -no_aliases - run: name: Running Linters diff --git a/Makefile b/Makefile index 663879d440..321b946988 100644 --- a/Makefile +++ b/Makefile @@ -16,7 +16,7 @@ build: $(docker) scripts/build_site.sh gen: - $(docker) scripts/gen_site.sh "" + $(docker) scripts/gen_site.sh "" -minify -no_aliases lint: $(docker) scripts/lint_site.sh @@ -25,4 +25,4 @@ serve: docker run -t -i --sig-proxy=true --rm -v $(shell pwd):/site -w /site -p 1313:1313 $(img) hugo serve --baseURL "http://${ISTIO_SERVE_DOMAIN}:1313/" --bind 0.0.0.0 --disableFastRender netlify: - scripts/gen_site.sh "$(baseurl)" + scripts/gen_site.sh "$(baseurl)" -minify -aliases diff --git a/content/about/feature-stages/index.md b/content/about/feature-stages/index.md index 6f645f2147..1f3c3f89f7 100644 --- a/content/about/feature-stages/index.md +++ b/content/about/feature-stages/index.md @@ -44,7 +44,7 @@ Below is our list of existing features and their current phases. This informatio | Feature | Phase |-------------------|------------------- | [Prometheus Integration](/docs/tasks/telemetry/querying-metrics/) | Stable -| [Local Logging (STDIO)](/docs/examples/telemetry/) | Stable +| [Local Logging (STDIO)](/docs/tasks/telemetry/) | Stable | [Statsd Integration](/docs/reference/config/policy-and-telemetry/adapters/statsd/) | Stable | [Client and Server Telemetry Reporting](/docs/concepts/policies-and-telemetry/) | Stable | [Service Dashboard in Grafana](/docs/tasks/telemetry/using-istio-dashboard/) | Beta diff --git a/content/blog/2018/traffic-mirroring/index.md b/content/blog/2018/traffic-mirroring/index.md index c4cb1f0d1b..83e9566ffd 100644 --- a/content/blog/2018/traffic-mirroring/index.md +++ b/content/blog/2018/traffic-mirroring/index.md @@ -9,7 +9,7 @@ keywords: [traffic-management,mirroring] Trying to enumerate all the possible combinations of test cases for testing services in non-production/test environments can be daunting. In some cases, you'll find that all of the effort that goes into cataloging these use cases doesn't match up to real production use cases. Ideally, we could use live production use cases and traffic to help illuminate all of the feature areas of the service under test that we might miss in more contrived testing environments. -Istio can help here. With the release of [Istio 0.5.0](/about/notes/0.5/), Istio can mirror traffic to help test your services. You can write route rules similar to the following to enable traffic mirroring: +Istio can help here. With the release of [Istio 0.5.0](/about/notes/older/0.5/), Istio can mirror traffic to help test your services. You can write route rules similar to the following to enable traffic mirroring: {{< text yaml >}} apiVersion: config.istio.io/v1alpha2 diff --git a/content/docs/concepts/security/index.md b/content/docs/concepts/security/index.md index 6ef9fb98df..e84e0b7771 100644 --- a/content/docs/concepts/security/index.md +++ b/content/docs/concepts/security/index.md @@ -100,7 +100,7 @@ Istio provides a more comprehensive security solution, including authentication, ## PKI -The Istio PKI is built on top of Istio Citadel and securely provisions strong workload identities to every workload. +The Istio PKI is built on top of Istio Citadel and securely provisions strong identities to every workload. Istio uses X.509 certificates to carry the identities in [SPIFFE](https://spiffe.io/) format. The PKI also automates the key & certificate rotation at scale. @@ -122,7 +122,7 @@ Currently we use different certificate key provisioning mechanisms for each scen which defines what service account or accounts can run a certain service. Pilot then passes the secure naming information to the sidecar Envoy. -### on-premises machines scenario +### On-premises machines scenario 1. Citadel creates a gRPC service to take [Certificate Signing Requests](https://en.wikipedia.org/wiki/Certificate_signing_request) (CSRs). @@ -135,7 +135,7 @@ Currently we use different certificate key provisioning mechanisms for each scen 1. The above CSR process repeats periodically for certificate and key rotation. -### Node Agent in Kubernetes +### Node agent in Kubernetes Istio provides the option of using node agent in Kubernetes for certificate and key provisioning, as shown in the figure below. Note that the identity provisioning flow for on-premises machines will be similar in the near future, we only describe the Kubernetes scenario here. @@ -165,7 +165,7 @@ In this section, we provide a few deployment guidelines and discuss a real-world If there are multiple service operators (a.k.a. [SREs](https://en.wikipedia.org/wiki/Site_reliability_engineering)) deploying different services in a medium- or large-size cluster, we recommend creating a separate [Kubernetes namespace](https://kubernetes.io/docs/tasks/administer-cluster/namespaces-walkthrough/) for each SRE team to isolate their access. - For example, you can create a `team1-ns` namespace for `team1`, and `team2-ns` namespace for `team2`, such +For example, you can create a `team1-ns` namespace for `team1`, and `team2-ns` namespace for `team2`, such that both teams cannot access each other's services. {{< warning >}} @@ -310,7 +310,7 @@ the request. For mutual TLS, Istio provides a [destination rule](/docs/concepts/ The operator can use the destination rule to instruct client proxies to make initial connections using TLS with the certificates expected on the server side. You can find out more about how mutual TLS works in Istio in -[PKI and identity section](/docs/concepts/security/mutual-tls/). +[Mutual TLS authentication](/docs/concepts/security/#mutual-tls-authentication). {{< image width="60%" link="./authn.svg" caption="Authentication Architecture" >}} diff --git a/content/docs/reference/commands/istioctl/index.html b/content/docs/reference/commands/istioctl/index.html index dfeb354963..a8a87a95de 100644 --- a/content/docs/reference/commands/istioctl/index.html +++ b/content/docs/reference/commands/istioctl/index.html @@ -945,7 +945,7 @@ istioctl verify-install -f istio-demo.yaml

istioctl kube-inject

-

kube-inject manually injects envoy sidecar into kubernetes +

kube-inject manually injects the Envoy sidecar into Kubernetes workloads. Unsupported resources are left unmodified so it is safe to run kube-inject over a single file that contains multiple Service, ConfigMap, Deployment, etc. definitions for a complex application. Its @@ -1112,7 +1112,7 @@ istioctl kube-inject -f deployment.yaml -o deployment-injected.yaml kubectl get deployment -o yaml | istioctl kube-inject -f - | kubectl apply -f - # Create a persistent version of the deployment with Envoy sidecar -# injected configuration from kubernetes configmap 'istio-inject' +# injected configuration from Kubernetes configmap 'istio-inject' istioctl kube-inject -f deployment.yaml -o deployment-injected.yaml --injectConfigMapName istio-inject diff --git a/content/docs/reference/config/policy-and-telemetry/adapters/cloudwatch/index.html b/content/docs/reference/config/policy-and-telemetry/adapters/cloudwatch/index.html index ffdc0f4b51..340460b744 100644 --- a/content/docs/reference/config/policy-and-telemetry/adapters/cloudwatch/index.html +++ b/content/docs/reference/config/policy-and-telemetry/adapters/cloudwatch/index.html @@ -20,9 +20,6 @@ number_of_entries: 4

To push metrics and logs to CloudWatch using this adapter you must provide AWS credentials to the AWS SDK. (see AWS docs).

-

To activate the CloudWatch adapter, operators need to provide configuration for the -cloudwatch adapter.

-

The handler configuration must contain the same metrics as the instance configuration. The metrics specified in both instance and handler configurations will be sent to CloudWatch.

diff --git a/content/docs/reference/config/policy-and-telemetry/templates/edge/index.html b/content/docs/reference/config/policy-and-telemetry/templates/edge/index.html index eaf8cc6656..2272e7b03c 100644 --- a/content/docs/reference/config/policy-and-telemetry/templates/edge/index.html +++ b/content/docs/reference/config/policy-and-telemetry/templates/edge/index.html @@ -16,11 +16,10 @@ number_of_entries: 1

When writing the configuration, the value for the fields associated with this template can either be a literal or an -expression. Please +expression. Please note that if the datatype of a field is not istio.mixer.adapter.model.v1beta1.Value, then the expression’s -inferred -type +inferred type must match the datatype of the field.

Example config:

diff --git a/content/docs/tasks/security/mtls-migration/index.md b/content/docs/tasks/security/mtls-migration/index.md index d2b0723442..22316edda1 100644 --- a/content/docs/tasks/security/mtls-migration/index.md +++ b/content/docs/tasks/security/mtls-migration/index.md @@ -26,7 +26,7 @@ down once the migration is done. ## Before you begin -* Understand Istio [authentication policy](/docs/concepts/security/authn-policy/) and related [mutual TLS authentication](/docs/concepts/security/mutual-tls/) concepts. +* Understand Istio [authentication policy](/docs/concepts/security/#authentication-policies) and related [mutual TLS authentication](/docs/concepts/security/#mutual-tls-authentication) concepts. * Have a Kubernetes cluster with Istio installed, without global mutual TLS enabled (e.g use `install/kubernetes/istio-demo.yaml` as described in [installation steps](/docs/setup/kubernetes/quick-start/#installation-steps), or set `global.mtls.enabled` to false using [Helm](/docs/setup/kubernetes/helm-install/)). diff --git a/content/docs/tasks/security/rbac-groups/index.md b/content/docs/tasks/security/rbac-groups/index.md index 923a15cf65..f94547455d 100644 --- a/content/docs/tasks/security/rbac-groups/index.md +++ b/content/docs/tasks/security/rbac-groups/index.md @@ -12,7 +12,7 @@ authorization and the authorization of list-typed claims in Istio. * Read the [authorization](/docs/concepts/security/#authorization) concept and go through the guide on how to -[configure Istio authorization](/docs/tasks/security/role-based-access-control). +[configure Istio authorization](/docs/tasks/security/authz-http). * Read the Istio [authentication policy](/docs/concepts/security/#authentication-policies) diff --git a/content_zh/blog/2018/istio-authorization/index.md b/content_zh/blog/2018/istio-authorization/index.md index e047f2b697..ad133900ce 100644 --- a/content_zh/blog/2018/istio-authorization/index.md +++ b/content_zh/blog/2018/istio-authorization/index.md @@ -62,7 +62,7 @@ keywords: [authorization,Role Based Access Control,security] ## 示例 -[授权任务](/zh/docs/tasks/security/role-based-access-control/)向您展示如何操作使用 Istio 的授权功能来控制命名空间级别 +[授权任务](/zh/docs/tasks/security/authz-http/)向您展示如何操作使用 Istio 的授权功能来控制命名空间级别 和服务级别访问 [Bookinfo 应用](/zh/docs/examples/bookinfo/)。在本节中，您将看到有关如何实现的更多示例使用 Istio 授权进行 微分割。 diff --git a/content_zh/docs/tasks/security/mtls-migration/index.md b/content_zh/docs/tasks/security/mtls-migration/index.md index 010078a6a9..36a80a8d5a 100644 --- a/content_zh/docs/tasks/security/mtls-migration/index.md +++ b/content_zh/docs/tasks/security/mtls-migration/index.md @@ -135,7 +135,7 @@ $ for from in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sle 503 {{< /text >}} -也就是说，如果不能把所有服务都迁移到 Istio (进行 Sidecar 注入)的话，就只能使用 `PERMISSIVE` 模式了。然而在配置为 `PERMISSIVE` 的时候，是不会对明文流量进行授权和鉴权方面的检查的。我们推荐使用 [RBAC](/zh/docs/tasks/security/role-based-access-control/) 来给不同的路径配置不同的授权策略。 +也就是说，如果不能把所有服务都迁移到 Istio (进行 Sidecar 注入)的话，就只能使用 `PERMISSIVE` 模式了。然而在配置为 `PERMISSIVE` 的时候，是不会对明文流量进行授权和鉴权方面的检查的。我们推荐使用 [RBAC](/zh/docs/tasks/security/authz-http/) 来给不同的路径配置不同的授权策略。 ## 清理 diff --git a/content_zh/docs/tasks/security/rbac-groups/index.md b/content_zh/docs/tasks/security/rbac-groups/index.md index 2d4f86599c..a2f038ff47 100644 --- a/content_zh/docs/tasks/security/rbac-groups/index.md +++ b/content_zh/docs/tasks/security/rbac-groups/index.md @@ -9,7 +9,7 @@ keywords: [security,authorization] ## 开始之前 -* 阅读[授权](/zh/docs/concepts/security/#授权和鉴权)概念并阅读有关如何配置 [Istio 授权的指南](/zh/docs/tasks/security/role-based-access-control)。 +* 阅读[授权](/zh/docs/concepts/security/#授权和鉴权)概念并阅读有关如何配置 [Istio 授权的指南](/zh/docs/tasks/security/authz-http)。 * 阅读 Istio 身份[验证策略](/zh/docs/concepts/security/#认证策略)和相关的[双向 TLS 身份验证](/zh/docs/concepts/security/#双向-tls-认证)概念。 diff --git a/content_zh/help/faq/security/k8s-health-checks.md b/content_zh/help/faq/security/k8s-health-checks.md index edecd6a964..e9ae17c553 100644 --- a/content_zh/help/faq/security/k8s-health-checks.md +++ b/content_zh/help/faq/security/k8s-health-checks.md @@ -8,7 +8,7 @@ weight: 50 ，因此当这个模式打开时他们可以接受 http 和双向 TLS 流量。这可以解决健康检查问题。 请记住，双向 TLS 没有强制执行，因为其他服务可以使用 http 流量与该服务进行通信。 -您可以使用单独的端口进行健康检查，并只在常规服务端口上启用双向 TLS。请参阅 [Istio 服务的健康检查](/docs/tasks/traffic-management/app-health-check/)了解更多信息。 +您可以使用单独的端口进行健康检查，并只在常规服务端口上启用双向 TLS。请参阅 [Istio 服务的健康检查](/help/ops/setup/app-health-check/)了解更多信息。 另一种解决方法是对健康检查使用 [liveness 命令](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command)，例如，可以在服务 Pod 中安装 `curl` 并在 Pod 内对自身执行 `curl` 操作。 diff --git a/layouts/_default/baseof.html b/layouts/_default/baseof.html index 78b8199ddd..31dcc7ec35 100644 --- a/layouts/_default/baseof.html +++ b/layouts/_default/baseof.html @@ -126,8 +126,7 @@ const buttonDownload = '{{ i18n "button_download" }}'; - - + @@ -137,6 +136,11 @@ {{ block "main" . }}{{ end }} {{ partial "footer.html" . }} + + {{ if .Scratch.Get "needPopper" }} + + {{ end }} +