mirror of https://github.com/istio/istio.io.git
Add a blurb in the footer about filing issues for incorrect web site content.
This commit is contained in:
Martin Taillefer
parent
eeec41de34
commit
ab01ebc976
|
|
@ -131,32 +131,32 @@ way to indicate the link target:
|
|||
- **Internet Link**. You use classic URL syntax, preferably with the HTTPS protocol, to reference
|
||||
files on the Internet:
|
||||
|
||||
```markdown
|
||||
[see here](https://mysite/myfile.html)
|
||||
```
|
||||
```markdown
|
||||
[see here](https://mysite/myfile.html)
|
||||
```
|
||||
|
||||
- **Relative Link**. You use relative links that start with a period to
|
||||
reference any content that is at the same level as the current file, or below within
|
||||
the hierarchy of the site:
|
||||
|
||||
```markdown
|
||||
[see here](./adir/anotherfile.html)
|
||||
```
|
||||
```markdown
|
||||
[see here](./adir/anotherfile.html)
|
||||
```
|
||||
|
||||
- **Absolute Link**. You use absolute links with the special \{\{home\}\} notation to reference content outside of the
|
||||
current hierarchy:
|
||||
|
||||
```markdown
|
||||
{% raw %}[see here]({{home}}/docs/adir/afile.html){% endraw %}
|
||||
```
|
||||
```markdown
|
||||
{% raw %}[see here]({{home}}/docs/adir/afile.html){% endraw %}
|
||||
```
|
||||
|
||||
In order to use \{\{home\}\} in a file,
|
||||
you need to make sure that the file contains the following
|
||||
line of boilerplate right after the block of front matter:
|
||||
In order to use \{\{home\}\} in a file,
|
||||
you need to make sure that the file contains the following
|
||||
line of boilerplate right after the block of front matter:
|
||||
|
||||
```markdown
|
||||
---
|
||||
{% raw %}{% include home.html %}{% endraw %}
|
||||
```
|
||||
|
||||
```markdown
|
||||
---
|
||||
{% raw %}{% include home.html %}{% endraw %}
|
||||
```
|
||||
|
||||
Adding this include statement is what defines the `home` variable that is used in the link target.
|
||||
Adding this include statement is what defines the `home` variable that is used in the link target.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,6 @@ This task describes how to configure Istio to expose external services to Istio
|
|||
You'll learn how to configure an external service and make requests to it via the Istio egress
|
||||
service or, alternatively, to simply enable direct calls to an external service.
|
||||
|
||||
|
||||
## Before you begin
|
||||
|
||||
* Setup Istio by following the instructions in the
|
||||
|
|
@ -34,24 +33,24 @@ from within your Istio cluster. In this task we will use
|
|||
|
||||
1. Register an external HTTP service:
|
||||
|
||||
```bash
|
||||
$ cat <<EOF | kubectl create -f -
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
```bash
|
||||
cat <<EOF | kubectl create -f -
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: httpbin
|
||||
spec:
|
||||
spec:
|
||||
type: ExternalName
|
||||
externalName: httpbin.org
|
||||
ports:
|
||||
- port: 80
|
||||
EOF
|
||||
```
|
||||
EOF
|
||||
```
|
||||
|
||||
2. Register an external HTTPS service:
|
||||
|
||||
```bash
|
||||
$ cat <<EOF | kubectl create -f -
|
||||
cat <<EOF | kubectl create -f -
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
|
|
@ -75,15 +74,15 @@ HTTP or port `443` for HTTPS.
|
|||
if you are using the sleep service, run the following commands:
|
||||
|
||||
```bash
|
||||
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
|
||||
$ kubectl exec -it $SOURCE_POD -c sleep bash
|
||||
export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
|
||||
kubectl exec -it $SOURCE_POD -c sleep bash
|
||||
```
|
||||
|
||||
2. Make a request to an external service using the `name` from the Service spec
|
||||
above followed by the path to the desired API endpoint:
|
||||
|
||||
```bash
|
||||
$ curl http://httpbin/headers
|
||||
curl http://httpbin/headers
|
||||
.. response ..
|
||||
```
|
||||
|
||||
|
|
@ -92,7 +91,7 @@ HTTP or port `443` for HTTPS.
|
|||
with the external service:
|
||||
|
||||
```bash
|
||||
$ curl http://securegoogle:443
|
||||
curl http://securegoogle:443
|
||||
.. response ..
|
||||
```
|
||||
|
||||
|
|
@ -113,24 +112,24 @@ to the sidecar proxy.
|
|||
The values used for internal IP range(s), however, depends on where your cluster is running.
|
||||
For example, with Minikube the range is 10.0.0.1/24, so you would start the sleep service like this:
|
||||
|
||||
```
|
||||
$ kubectl apply -f <(istioctl kube-inject -f sleep.yaml --includeIPRanges=10.0.0.1/24)
|
||||
```bash
|
||||
kubectl apply -f <(istioctl kube-inject -f sleep.yaml --includeIPRanges=10.0.0.1/24)
|
||||
```
|
||||
|
||||
On IBM Bluemix, use:
|
||||
|
||||
```
|
||||
$ kubectl apply -f <(istioctl kube-inject -f sleep.yaml --includeIPRanges=172.30.0.0/16,172.20.0.0/16)
|
||||
```bash
|
||||
kubectl apply -f <(istioctl kube-inject -f sleep.yaml --includeIPRanges=172.30.0.0/16,172.20.0.0/16)
|
||||
```
|
||||
|
||||
On Google Container Engine (GKE) the ranges are not fixed, so you will
|
||||
need to run the `gcloud container clusters describe` command to determine the ranges to use. For example:
|
||||
|
||||
```
|
||||
$ gcloud container clusters describe benchmark-alpha --zone=us-central1-a | grep -e clusterIpv4Cidr -e servicesIpv4Cidr
|
||||
```bash
|
||||
gcloud container clusters describe benchmark-alpha --zone=us-central1-a | grep -e clusterIpv4Cidr -e servicesIpv4Cidr
|
||||
clusterIpv4Cidr: 10.4.0.0/14
|
||||
servicesIpv4Cidr: 10.7.240.0/20
|
||||
$ kubectl apply -f <(istioctl kube-inject -f sleep.yaml --includeIPRanges=10.4.0.0/14,10.7.240.0/20)
|
||||
kubectl apply -f <(istioctl kube-inject -f sleep.yaml --includeIPRanges=10.4.0.0/14,10.7.240.0/20)
|
||||
```
|
||||
|
||||
After starting your service this way, the Istio sidecar will only intercept and manage internal requests
|
||||
|
|
@ -138,12 +137,11 @@ within the cluster. Any external request will simply bypass the sidecar and go s
|
|||
destination.
|
||||
|
||||
```bash
|
||||
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
|
||||
$ kubectl exec -it $SOURCE_POD -c sleep curl http://httpbin.org/headers
|
||||
export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
|
||||
kubectl exec -it $SOURCE_POD -c sleep curl http://httpbin.org/headers
|
||||
.. response ..
|
||||
```
|
||||
|
||||
|
||||
## Understanding what happened
|
||||
|
||||
In this task we looked at two ways to call external services from within an Istio cluster:
|
||||
|
|
@ -160,7 +158,6 @@ The second approach bypasses the Istio sidecar proxy, giving your services direc
|
|||
external URL. However, configuring the proxy this way does require
|
||||
cloud provider specific knowledge and configuration.
|
||||
|
||||
|
||||
## What's next
|
||||
|
||||
* See how to make requests to services inside a cluster by using the [Ingress Controller](./ingress.html).
|
||||
|
|
|
|||
|
|
@ -2,7 +2,10 @@
|
|||
<div class="container">
|
||||
<div class="left-links">
|
||||
<p class="description">Copyright © 2017 Istio Authors</p>
|
||||
<p class="description">This site was built on {{site.time | date_to_string}}</p>
|
||||
<p class="description">This site was built on {{site.time | date_to_string | split: ' ' | join: '-'}}</p>
|
||||
<p class="description">Found something inaccurate or missing?
|
||||
<a href="https://github.com/istio/istio.github.io/issues/new?title=Issue with {{page.path}}">File an issue</a>
|
||||
and we'll get right on it.</p>
|
||||
</div>
|
||||
<div class="right-links">
|
||||
<div class="col-md-3 col-sm-3 col-xs-12 footer-documentation">
|
||||
|
|
|
|||
Loading…
Reference in New Issue