mirror of https://github.com/istio/istio.io.git
Added more lint rules and fix offenders (#3227)
- Ensure that references to GitHub content use the proper annotations so
we get links to the correct branches.
- Added a check to make sure content is not using blockquotes (instead of
{{< warning >}}, {{< tip >}}, and {{< idea >}}. This check is currently
disabled, pending the Chinese content being updated.
- Fix a few violations of these new checks.
This commit is contained in:
Martin Taillefer
GitHub
parent
d25753f93b
commit
b3db41da99
|
|
@ -215,21 +215,21 @@ current hierarchy:
|
|||
There are a few ways to reference files from GitHub:
|
||||
|
||||
- **{{</* github_file */>}}** is how you reference individual files in GitHub such as yaml files. This
|
||||
produces a link to `https://raw.githubusercontent.com/istio/istio/...`
|
||||
produces a link to `https://raw.githubusercontent.com/istio/istio*`
|
||||
|
||||
{{< text markdown >}}
|
||||
[liveness]({{</* github_file */>}}/samples/health-check/liveness-command.yaml)
|
||||
{{< /text >}}
|
||||
|
||||
- **{{</* github_tree */>}}** is how you reference a directory tree in GitHub. This produces a link to
|
||||
`https://github.com/istio/istio/tree/...`
|
||||
`https://github.com/istio/istio/tree*`
|
||||
|
||||
{{< text markdown >}}
|
||||
[httpbin]({{</* github_tree */>}}/samples/httpbin)
|
||||
{{< /text >}}
|
||||
|
||||
- **{{</* github_blob */>}}** is how you reference a file in GitHub sources. This produces a link to
|
||||
`https://github.com/istio/istio/blob/...`
|
||||
`https://github.com/istio/istio/blob*`
|
||||
|
||||
{{< text markdown >}}
|
||||
[RawVM MySQL]({{</* github_blob */>}}/samples/rawvm/README.md)
|
||||
|
|
|
|||
|
|
@ -31,9 +31,11 @@ actions are not expected, but a clean separation of the tenants is still require
|
|||
Potential future Istio multi-tenant deployment models are described at the bottom of this
|
||||
blog.
|
||||
|
||||
>Note: This blog is a high-level description of how to deploy Istio in a
|
||||
{{< tip >}}
|
||||
This blog is a high-level description of how to deploy Istio in a
|
||||
limited multi-tenancy environment. The [docs](/docs/) section will be updated
|
||||
when official multi-tenancy support is provided.
|
||||
{{< /tip >}}
|
||||
|
||||
## Deployment
|
||||
|
||||
|
|
|
|||
|
|
@ -44,9 +44,9 @@ The point of a dependency graph is to know which clients depend on a particular
|
|||
|
||||
### AppSwitch model and constructs
|
||||
|
||||
Now that we have a conceptual understanding of AppSwitch’s high-level approach, let’s look at the constructs involved. But first a quick summary of the usage model is in order. Even though it is written for a different context, reviewing my earlier [blog](/blog/2018/delayering-istio/delayering-istio) on this topic would be useful as well. For completeness, let me also note AppSwitch doesn’t bother with non-network dependencies. For example it may be possible for two services to interact using IPC mechanisms or through the shared file system. Processes with deep ties like that are typically part of the same service anyway and don’t require framework’s intervention for ordering.
|
||||
Now that we have a conceptual understanding of AppSwitch’s high-level approach, let’s look at the constructs involved. But first a quick summary of the usage model is in order. Even though it is written for a different context, reviewing my earlier [blog](/blog/2018/delayering-istio/) on this topic would be useful as well. For completeness, let me also note AppSwitch doesn’t bother with non-network dependencies. For example it may be possible for two services to interact using IPC mechanisms or through the shared file system. Processes with deep ties like that are typically part of the same service anyway and don’t require framework’s intervention for ordering.
|
||||
|
||||
At its core, AppSwitch is built on a mechanism that allows instrumenting the BSD socket API and other related calls like `fcntl` and `ioctl` that deal with sockets. As interesting as the details of its implementation are, it’s going to distract us from the main topic, so I’d just summarize the key properties that distinguish it from other implementations. (1) It’s fast. It uses a combination of `seccomp` filtering and binary instrumentation to aggressively limit intervening with application’s normal execution. AppSwitch is particularly suited for service mesh and application networking use cases given that it implements those features without ever having to actually touch the data. In contrast, network level approaches incur per-packet cost. Take a look at this [blog](/blog/2018/delayering-istio/delayering-istio) for some of the performance measurements. (2) It doesn’t require any kernel support, kernel module or a patch and works on standard distro kernels (3) It can run as regular user (no root). In fact, the mechanism can even make it possible to run [Docker daemon without root](https://linuxpiter.com/en/materials/2478) by removing root requirement to network containers (4) It doesn’t require any changes to the applications whatsoever and works for any type of application -- from WebSphere ND and SAP to custom C apps to statically linked Golang apps. Only requirement at this point is Linux/x86.
|
||||
At its core, AppSwitch is built on a mechanism that allows instrumenting the BSD socket API and other related calls like `fcntl` and `ioctl` that deal with sockets. As interesting as the details of its implementation are, it’s going to distract us from the main topic, so I’d just summarize the key properties that distinguish it from other implementations. (1) It’s fast. It uses a combination of `seccomp` filtering and binary instrumentation to aggressively limit intervening with application’s normal execution. AppSwitch is particularly suited for service mesh and application networking use cases given that it implements those features without ever having to actually touch the data. In contrast, network level approaches incur per-packet cost. Take a look at this [blog](/blog/2018/delayering-istio/) for some of the performance measurements. (2) It doesn’t require any kernel support, kernel module or a patch and works on standard distro kernels (3) It can run as regular user (no root). In fact, the mechanism can even make it possible to run [Docker daemon without root](https://linuxpiter.com/en/materials/2478) by removing root requirement to network containers (4) It doesn’t require any changes to the applications whatsoever and works for any type of application -- from WebSphere ND and SAP to custom C apps to statically linked Golang apps. Only requirement at this point is Linux/x86.
|
||||
|
||||
### Decoupling services from their references
|
||||
|
||||
|
|
@ -70,7 +70,7 @@ What if the application times out based on its own internal timer? Truth be tol
|
|||
|
||||
Service references can be used to address the Istio sidecar dependency issue mentioned earlier. AppSwitch allows the IP:port specified as part of a service reference to be a wildcard. That is, the service reference IP address can be a netmask indicating the IP address range to be captured. If the label selector of the service reference points to the sidecar service, then all outgoing connections of any application for which this service reference is applied, will be transparently redirected to the sidecar. And of course, the service reference remains valid while sidecar is still coming up and the race is removed.
|
||||
|
||||
Using service references for sidecar dependency ordering also implicitly redirects application’s connections to the sidecar without requiring iptables and attendant privilege issues. Essentially it works as if the application is directly making connections to the sidecar rather than the target destination, leaving the sidecar in charge of what to do. AppSwitch would interject metadata about the original destination etc. into the data stream of the connection using the proxy protocol that the sidecar could decode before passing the connection through to the application. Some of these details were discussed [here](/blog/2018/delayering-istio/delayering-istio). That takes care of outbound connections but what about incoming connections? With all services and their sidecars running under AppSwitch, any incoming connections that would have come from remote nodes would be redirected to their respective remote sidecars. So nothing special to do about incoming connections.
|
||||
Using service references for sidecar dependency ordering also implicitly redirects application’s connections to the sidecar without requiring iptables and attendant privilege issues. Essentially it works as if the application is directly making connections to the sidecar rather than the target destination, leaving the sidecar in charge of what to do. AppSwitch would interject metadata about the original destination etc. into the data stream of the connection using the proxy protocol that the sidecar could decode before passing the connection through to the application. Some of these details were discussed [here](/blog/2018/delayering-istio/). That takes care of outbound connections but what about incoming connections? With all services and their sidecars running under AppSwitch, any incoming connections that would have come from remote nodes would be redirected to their respective remote sidecars. So nothing special to do about incoming connections.
|
||||
|
||||
## Summary
|
||||
|
||||
|
|
|
|||
|
|
@ -98,10 +98,12 @@ istio-pilot-58c65f74bc-2f5xn 1/1 Running 0 1m
|
|||
|
||||
* For option 2, uninstall using Helm:
|
||||
|
||||
> Uninstalling this chart does not delete Istio's registered CRDs. Istio, by design, expects
|
||||
> CRDs to leak into the Kubernetes environment. As CRDs contain all the runtime configuration
|
||||
> data needed to configure Istio. Because of this, we consider it better for operators to
|
||||
> explicitly delete the runtime configuration data rather than unexpectedly lose it.
|
||||
{{< warning >}}
|
||||
Uninstalling this chart does not delete Istio's registered CRDs. Istio, by design, expects
|
||||
CRDs to leak into the Kubernetes environment. As CRDs contain all the runtime configuration
|
||||
data needed to configure Istio. Because of this, we consider it better for operators to
|
||||
explicitly delete the runtime configuration data rather than unexpectedly lose it.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm delete --purge istio-minimal
|
||||
|
|
|
|||
|
|
@ -210,7 +210,7 @@ The script is included in the [Istio installation package](/docs/setup/kubernete
|
|||
Download and run the script with the following command:
|
||||
|
||||
{{< text bash >}}
|
||||
$ curl -L https://raw.githubusercontent.com/istio/istio/master/tools/convert_RbacConfig_to_ClusterRbacConfig.sh | sh -
|
||||
$ curl -L {{% github_file %}}/tools/convert_RbacConfig_to_ClusterRbacConfig.sh | sh -
|
||||
{{< /text >}}
|
||||
|
||||
The script automates the following operations:
|
||||
|
|
|
|||
|
|
@ -137,11 +137,12 @@ spec:
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
>
|
||||
{{< tip >}}
|
||||
* Host value `*.local` to limit matches only to services in cluster, as opposed to external services. Also note, there is no restriction on the name or
|
||||
namespace for destination rule.
|
||||
* With `ISTIO_MUTUAL` TLS mode, Istio will set the path for key and certificates (e.g client certificate, private key and CA certificates) according to
|
||||
its internal implementation.
|
||||
{{< /tip >}}
|
||||
|
||||
Don’t forget that destination rules are also used for non-auth reasons such as setting up canarying, but the same order of precedence applies. So if a service
|
||||
requires a specific destination rule for any reason - for example, for a configuration load balancer - the rule must contain a similar TLS block with
|
||||
|
|
@ -604,7 +605,7 @@ spec:
|
|||
origins:
|
||||
- jwt:
|
||||
issuer: "testing@secure.istio.io"
|
||||
jwksUri: "https://raw.githubusercontent.com/istio/istio/master/security/tools/jwt/samples/jwks.json"
|
||||
jwksUri: "{{< github_file >}}/security/tools/jwt/samples/jwks.json"
|
||||
trigger_rules:
|
||||
- excluded_paths:
|
||||
- exact: /user-agent
|
||||
|
|
|
|||
|
|
@ -46,9 +46,11 @@ If you are using a namespace other than `default`, use `kubectl -n namespace ...
|
|||
|
||||
* Run the following commands to remove any existing RBAC policies:
|
||||
|
||||
> You could keep existing policies but you will need to make some changes to the `constraints` and `properties` field
|
||||
{{< tip >}}
|
||||
You could keep existing policies but you will need to make some changes to the `constraints` and `properties` field
|
||||
in the policy, see [constraints and properties](/docs/reference/config/authorization/constraints-and-properties/)
|
||||
for the list of supported keys in `constraints` and `properties`.
|
||||
{{< /tip >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete servicerole --all
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@ from within your Istio cluster. This task shows you how to access an external HT
|
|||
1. Check the log of the sidecar proxy of `SOURCE_POD`:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl logs $SOURCE_POD -c istio-proxy | tail
|
||||
$ kubectl logs $SOURCE_POD -c istio-proxy | tail
|
||||
[2019-01-24T12:48:54.977Z] "- - -" 0 - 601 17766 1289 - "-" "-" "-" "-" "172.217.161.36:443" outbound|443||www.google.com 172.30.109.82:59480 172.217.161.36:443 172.30.109.82:59478 www.google.com
|
||||
{{< /text >}}
|
||||
|
||||
|
|
@ -372,8 +372,10 @@ for HTTP traffic in Istio is discouraged.)
|
|||
<title>CNN International - Breaking News, US News, World News and Video</title>
|
||||
{{< /text >}}
|
||||
|
||||
> It might take time for the configuration change to propagate so you might still get connection errors.
|
||||
{{< warning >}}
|
||||
It might take time for the configuration change to propagate so you might still get connection errors.
|
||||
Wait for several seconds and then retry the last command.
|
||||
{{< /warning >}}
|
||||
|
||||
Note that the requests to port 80 are blocked for all the external services since Istio by default has HTTP services
|
||||
that run on port 80. Also note that if you install Istio with allowed access to all the external services you loose
|
||||
|
|
|
|||
|
|
@ -131,19 +131,19 @@ keywords: [keyword1,keyword2,...]
|
|||
|
||||
有几种引用 GitHub 文件的方法：
|
||||
|
||||
- **{{</* github_file */>}}** 可以用来引用单独的 GitHub 文件，例如 yaml，会生成类似 `https://raw.githubusercontent.com/istio/istio/...` 的链接：
|
||||
- **{{</* github_file */>}}** 可以用来引用单独的 GitHub 文件，例如 yaml，会生成类似 `https://raw.githubusercontent.com/istio/istio*` 的链接：
|
||||
|
||||
{{< text markdown >}}
|
||||
[liveness]({{</* github_file */>}}/samples/health-check/liveness-command.yaml)
|
||||
{{< /text >}}
|
||||
|
||||
- **{{</* github_tree */>}}** 用于引用 GitHub 中的目录树，会转换成如下链接：`https://github.com/istio/istio/tree/...`
|
||||
- **{{</* github_tree */>}}** 用于引用 GitHub 中的目录树，会转换成如下链接：`https://github.com/istio/istio/tree*`
|
||||
|
||||
{{< text markdown >}}
|
||||
[httpbin]({{</* github_tree */>}}/samples/httpbin)
|
||||
{{< /text >}}
|
||||
|
||||
- **{{</* github_blob */>}}** 用来引用 GitHub 资源，生成如下链接：`https://github.com/istio/istio/blob/...`
|
||||
- **{{</* github_blob */>}}** 用来引用 GitHub 资源，生成如下链接：`https://github.com/istio/istio/blob*`
|
||||
|
||||
{{< text markdown >}}
|
||||
[RawVM MySQL]({{</* github_blob */>}}/samples/rawvm/README.md)
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ keywords: [kubernetes,gke,google]
|
|||
|
||||
1. 一旦你的账户和项目启用，点击下面的链接，打开 Deployment Manager。
|
||||
|
||||
[Istio GKE Deployment Manager](https://accounts.google.com/signin/v2/identifier?service=cloudconsole&continue=https://console.cloud.google.com/launcher/config?templateurl={{< github_file >}}/install/gcp/deployment_manager/istio-cluster.jinja&followup=https://console.cloud.google.com/launcher/config?templateurl=https://raw.githubusercontent.com/istio/istio/master/install/gcp/deployment_manager/istio-cluster.jinja&flowName=GlifWebSignIn&flowEntry=ServiceLogin)
|
||||
[Istio GKE Deployment Manager](https://accounts.google.com/signin/v2/identifier?service=cloudconsole&continue=https://console.cloud.google.com/launcher/config?templateurl={{< github_file >}}/install/gcp/deployment_manager/istio-cluster.jinja&followup=https://console.cloud.google.com/launcher/config?templateurl={{< github_file >}}/install/gcp/deployment_manager/istio-cluster.jinja&flowName=GlifWebSignIn&flowEntry=ServiceLogin)
|
||||
|
||||
就像其他教程中的“如何访问已安装的功能”一样，我们也建议保留默认设置。工具会默认创建一个特殊设置的 GKE alpha cluster，然后安装 Istio [控制平面](/zh/docs/concepts/what-is-istio/#架构)、
|
||||
[Bookinfo](/zh/docs/examples/bookinfo/) 样例应用、
|
||||
|
|
|
|||
|
|
@ -242,7 +242,7 @@ spec:
|
|||
下载并运行如下命令：
|
||||
|
||||
{{< text bash >}}
|
||||
$ curl -L https://raw.githubusercontent.com/istio/istio/master/tools/convert_RbacConfig_to_ClusterRbacConfig.sh | sh -
|
||||
$ curl -L {{% github_file %}}git/tools/convert_RbacConfig_to_ClusterRbacConfig.sh | sh -
|
||||
{{< /text >}}
|
||||
|
||||
这个脚本自动化下如下操作：
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ keywords: [telemetry,visualization]
|
|||
|
||||
[Kiali 安装指南](https://www.kiali.io/gettingstarted/)中还介绍了不借助 Helm 安装 Kiali 的方法。
|
||||
|
||||
在 Istio 命名空间中创建一个 Secret，作为 Kiali 的认证凭据。[Helm README](https://github.com/istio/istio/blob/master/install/kubernetes/helm/istio/README.md#installing-the-chart) 中介绍了更多细节。修改并运行下列命令：
|
||||
在 Istio 命名空间中创建一个 Secret，作为 Kiali 的认证凭据。[Helm README]({{< github_blob >}}/install/kubernetes/helm/istio/README.md#installing-the-chart) 中介绍了更多细节。修改并运行下列命令：
|
||||
|
||||
{{< text bash >}}
|
||||
$ USERNAME=$(echo -n 'admin' | base64)
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ DISABLE_EXTERNAL=${INTERNAL_ONLY:-false}
|
|||
|
||||
# This performs spell checking and style checking over markdown files in a content
|
||||
# directory. It transforms the shortcode sequences we use to annotate code blocks
|
||||
# blocks into classic markdown ``` code blocks, so that the linters aren't confused
|
||||
# into classic markdown ``` code blocks, so that the linters aren't confused
|
||||
# by the code blocks
|
||||
check_content() {
|
||||
DIR=$1
|
||||
|
|
@ -62,6 +62,27 @@ check_content() {
|
|||
FAILED=1
|
||||
fi
|
||||
|
||||
grep -nr -e "https://github.com/istio/istio/blob/" .
|
||||
if [[ "$?" == "0" ]]
|
||||
then
|
||||
echo "Ensure markdown content uses {{< github_blob >}}"
|
||||
FAILED=1
|
||||
fi
|
||||
|
||||
grep -nr -e "https://github.com/istio/istio/tree/" .
|
||||
if [[ "$?" == "0" ]]
|
||||
then
|
||||
echo "Ensure markdown content uses {{< github_tree >}}"
|
||||
FAILED=1
|
||||
fi
|
||||
|
||||
grep -nr -e "https://raw.githubusercontent.com/istio/istio/" .
|
||||
if [[ "$?" == "0" ]]
|
||||
then
|
||||
echo "Ensure markdown content uses {{< github_file >}}"
|
||||
FAILED=1
|
||||
fi
|
||||
|
||||
# go back whence we came
|
||||
popd >/dev/null
|
||||
|
||||
|
|
@ -79,6 +100,17 @@ then
|
|||
FAILED=1
|
||||
fi
|
||||
|
||||
# disabled until the Chinese content has been updated
|
||||
#for f in `find ./public -type f -name '*.html'`
|
||||
#do
|
||||
# grep -l -e "blockquote" $f
|
||||
# if [[ "$?" == "0" ]]
|
||||
# then
|
||||
# echo "Ensure site use {{< tip >}}, {{< warning >}} and {{< idea >}} instead of block quotes"
|
||||
# FAILED=1
|
||||
# fi
|
||||
#done
|
||||
|
||||
htmlproofer ./public --assume-extension --check-html --disable_external ${DISABLE_EXTERNAL} --check-external-hash --check-opengraph --timeframe 2d --storage-dir .htmlproofer --url-ignore "/localhost/,/github.com/istio/istio.io/edit/master/,/github.com/istio/istio/issues/new/choose/,/groups.google.com/forum/,/www.trulia.com/"
|
||||
if [[ "$?" != "0" ]]
|
||||
then
|
||||
|
|
|
|||
Loading…
Reference in New Issue