Absolutize links that leave the docs/ tree to go anywhere other than
to examples/ or back to docs/
This commit is contained in:
@@ -148,7 +148,7 @@ with future high-availability support.
|
||||
|
||||
There are [client libraries](../devel/client-libraries.md) for accessing the API
|
||||
from several languages. The Kubernetes project-supported
|
||||
[Go](../../pkg/client/)
|
||||
[Go](http://releases.k8s.io/HEAD/pkg/client/)
|
||||
client library can use the same [kubeconfig file](kubeconfig-file.md)
|
||||
as the kubectl CLI does to locate and authenticate to the apiserver.
|
||||
|
||||
|
@@ -145,7 +145,7 @@ To determine if a container cannot be scheduled or is being killed due to resour
|
||||
|
||||
The resource usage of a pod is reported as part of the Pod status.
|
||||
|
||||
If [optional monitoring](../../cluster/addons/cluster-monitoring/README.md) is configured for your cluster,
|
||||
If [optional monitoring](http://releases.k8s.io/HEAD/cluster/addons/cluster-monitoring/README.md) is configured for your cluster,
|
||||
then pod resource usage can be retrieved from the monitoring system.
|
||||
|
||||
## Troubleshooting
|
||||
|
@@ -160,7 +160,7 @@ You should now be able to curl the nginx Service on `10.0.116.146:80` from any n
|
||||
|
||||
## Accessing the Service
|
||||
|
||||
Kubernetes supports 2 primary modes of finding a Service - environment variables and DNS. The former works out of the box while the latter requires the [kube-dns cluster addon](../../cluster/addons/dns/README.md).
|
||||
Kubernetes supports 2 primary modes of finding a Service - environment variables and DNS. The former works out of the box while the latter requires the [kube-dns cluster addon](http://releases.k8s.io/HEAD/cluster/addons/dns/README.md).
|
||||
|
||||
### Environment Variables
|
||||
|
||||
@@ -199,7 +199,7 @@ kube-dns <none> k8s-app=kube-dns 10.0.0.10 53/UDP
|
||||
53/TCP
|
||||
```
|
||||
|
||||
If it isn’t running, you can [enable it](../../cluster/addons/dns/README.md#how-do-i-configure-it). The rest of this section will assume you have a Service with a long lived ip (nginxsvc), and a dns server that has assigned a name to that ip (the kube-dns cluster addon), so you can talk to the Service from any pod in your cluster using standard methods (e.g. gethostbyname). Let’s create another pod to test this:
|
||||
If it isn’t running, you can [enable it](http://releases.k8s.io/HEAD/cluster/addons/dns/README.md#how-do-i-configure-it). The rest of this section will assume you have a Service with a long lived ip (nginxsvc), and a dns server that has assigned a name to that ip (the kube-dns cluster addon), so you can talk to the Service from any pod in your cluster using standard methods (e.g. gethostbyname). Let’s create another pod to test this:
|
||||
|
||||
```yaml
|
||||
$ cat curlpod.yaml
|
||||
|
@@ -83,7 +83,7 @@ FOO_SERVICE_HOST=<the host the service is running on>
|
||||
FOO_SERVICE_PORT=<the port the service is running on>
|
||||
```
|
||||
|
||||
Services have dedicated IP address, and are also surfaced to the container via DNS (If [DNS addon](../../cluster/addons/dns/) is enabled). Of course DNS is still not an enumerable protocol, so we will continue to provide environment variables so that containers can do discovery.
|
||||
Services have dedicated IP address, and are also surfaced to the container via DNS (If [DNS addon](http://releases.k8s.io/HEAD/cluster/addons/dns/) is enabled). Of course DNS is still not an enumerable protocol, so we will continue to provide environment variables so that containers can do discovery.
|
||||
|
||||
## Container Hooks
|
||||
|
||||
|
@@ -111,7 +111,7 @@ describes how to ingest cluster level logs into Elasticsearch and view them usin
|
||||
## Ingesting Application Log Files
|
||||
|
||||
Cluster level logging only collects the standard output and standard error output of the applications
|
||||
running in containers. The guide [Collecting log files within containers with Fluentd](../../contrib/logging/fluentd-sidecar-gcp/README.md) explains how the log files of applications can also be ingested into Google Cloud logging.
|
||||
running in containers. The guide [Collecting log files within containers with Fluentd](http://releases.k8s.io/HEAD/contrib/logging/fluentd-sidecar-gcp/README.md) explains how the log files of applications can also be ingested into Google Cloud logging.
|
||||
|
||||
## Known issues
|
||||
|
||||
|
@@ -206,7 +206,7 @@ spec:
|
||||
|
||||
[Pods](pods.md) support running multiple containers co-located together. They can be used to host vertically integrated application stacks, but their primary motivation is to support auxiliary helper programs that assist the primary application. Typical examples are data pullers, data pushers, and proxies.
|
||||
|
||||
Such containers typically need to communicate with one another, often through the file system. This can be achieved by mounting the same volume into both containers. An example of this pattern would be a web server with a [program that polls a git repository](../../contrib/git-sync/) for new updates:
|
||||
Such containers typically need to communicate with one another, often through the file system. This can be achieved by mounting the same volume into both containers. An example of this pattern would be a web server with a [program that polls a git repository](http://releases.k8s.io/HEAD/contrib/git-sync/) for new updates:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
@@ -294,7 +294,7 @@ variables and DNS.
|
||||
When a `Pod` is run on a `Node`, the kubelet adds a set of environment variables
|
||||
for each active `Service`. It supports both [Docker links
|
||||
compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see
|
||||
[makeLinkVariables](../../pkg/kubelet/envvars/envvars.go#L49))
|
||||
[makeLinkVariables](http://releases.k8s.io/HEAD/pkg/kubelet/envvars/envvars.go#L49))
|
||||
and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables,
|
||||
where the Service name is upper-cased and dashes are converted to underscores.
|
||||
|
||||
@@ -319,7 +319,7 @@ variables will not be populated. DNS does not have this restriction.
|
||||
### DNS
|
||||
|
||||
An optional (though strongly recommended) [cluster
|
||||
add-on](../../cluster/addons/README.md) is a DNS server. The
|
||||
add-on](http://releases.k8s.io/HEAD/cluster/addons/README.md) is a DNS server. The
|
||||
DNS server watches the Kubernetes API for new `Services` and creates a set of
|
||||
DNS records for each. If DNS has been enabled throughout the cluster then all
|
||||
`Pods` should be able to do name resolution of `Services` automatically.
|
||||
|
@@ -46,7 +46,7 @@ kubectl create -f cluster/addons/kube-ui/kube-ui-rc.yaml --namespace=kube-system
|
||||
kubectl create -f cluster/addons/kube-ui/kube-ui-svc.yaml --namespace=kube-system
|
||||
```
|
||||
|
||||
Normally, this should be taken care of automatically by the [`kube-addons.sh`](../../cluster/saltbase/salt/kube-addons/kube-addons.sh) script that runs on the master.
|
||||
Normally, this should be taken care of automatically by the [`kube-addons.sh`](http://releases.k8s.io/HEAD/cluster/saltbase/salt/kube-addons/kube-addons.sh) script that runs on the master.
|
||||
|
||||
## Using the UI
|
||||
|
||||
@@ -79,7 +79,7 @@ Other views (Pods, Nodes, Replication Controllers, Services, and Events) simply
|
||||
|
||||
## More Information
|
||||
|
||||
For more information, see the [Kubernetes UI development document](../../www/README.md) in the www directory.
|
||||
For more information, see the [Kubernetes UI development document](http://releases.k8s.io/HEAD/www/README.md) in the www directory.
|
||||
|
||||
|
||||
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
||||
|
Reference in New Issue
Block a user