From ea22ffe05c208d68a9b133b52290a5284c9370c9 Mon Sep 17 00:00:00 2001 From: Jan Pazdziora Date: Tue, 26 Sep 2017 11:45:02 +0200 Subject: [PATCH] The ../user-guide links do not seem to work anymore. --- contributors/design-proposals/apps/deploy.md | 2 +- contributors/design-proposals/aws/aws_under_the_hood.md | 8 ++++---- .../design-proposals/cli/simple-rolling-update.md | 4 ++-- contributors/design-proposals/network/networking.md | 2 +- contributors/design-proposals/scheduling/resources.md | 4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/contributors/design-proposals/apps/deploy.md b/contributors/design-proposals/apps/deploy.md index 5e5ac75ab..0165dd9db 100644 --- a/contributors/design-proposals/apps/deploy.md +++ b/contributors/design-proposals/apps/deploy.md @@ -19,7 +19,7 @@ ## Motivation -Users can use [Deployments](../user-guide/deployments.md) or [`kubectl rolling-update`](../user-guide/kubectl/kubectl_rolling-update.md) to deploy in their Kubernetes clusters. A Deployment provides declarative update for Pods and ReplicationControllers, whereas `rolling-update` allows the users to update their earlier deployment without worrying about schemas and configurations. Users need a way that's similar to `rolling-update` to manage their Deployments more easily. +Users can use [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) or [`kubectl rolling-update`](https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/) to deploy in their Kubernetes clusters. A Deployment provides declarative update for Pods and ReplicationControllers, whereas `rolling-update` allows the users to update their earlier deployment without worrying about schemas and configurations. Users need a way that's similar to `rolling-update` to manage their Deployments more easily. `rolling-update` expects ReplicationController as the only resource type it deals with. It's not trivial to support exactly the same behavior with Deployment, which requires: - Print out scaling up/down events. diff --git a/contributors/design-proposals/aws/aws_under_the_hood.md b/contributors/design-proposals/aws/aws_under_the_hood.md index 603e794a5..ec8b0740c 100644 --- a/contributors/design-proposals/aws/aws_under_the_hood.md +++ b/contributors/design-proposals/aws/aws_under_the_hood.md @@ -47,13 +47,13 @@ kube-up. ### Storage -AWS supports persistent volumes by using [Elastic Block Store (EBS)](../user-guide/volumes.md#awselasticblockstore). +AWS supports persistent volumes by using [Elastic Block Store (EBS)](https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore). These can then be attached to pods that should store persistent data (e.g. if you're running a database). By default, nodes in AWS use [instance storage](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) unless you create pods with persistent volumes -[(EBS)](../user-guide/volumes.md#awselasticblockstore). In general, Kubernetes +[(EBS)](https://kubernetes.io/docs/concepts/storage/volumes/#awselasticblockstore). In general, Kubernetes containers do not have persistent storage unless you attach a persistent volume, and so nodes on AWS use instance storage. Instance storage is cheaper, often faster, and historically more reliable. Unless you can make do with @@ -112,8 +112,8 @@ ELB has some restrictions: on ELB annotations for pods speaking HTTP). To work with these restrictions, in Kubernetes, [LoadBalancer -services](../user-guide/services.md#type-loadbalancer) are exposed as -[NodePort services](../user-guide/services.md#type-nodeport). Then +services](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer) are exposed as +[NodePort services](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport). Then kube-proxy listens externally on the cluster-wide port that's assigned to NodePort services and forwards traffic to the corresponding pods. diff --git a/contributors/design-proposals/cli/simple-rolling-update.md b/contributors/design-proposals/cli/simple-rolling-update.md index ea3853117..32d758202 100644 --- a/contributors/design-proposals/cli/simple-rolling-update.md +++ b/contributors/design-proposals/cli/simple-rolling-update.md @@ -1,10 +1,10 @@ ## Simple rolling update This is a lightweight design document for simple -[rolling update](../user-guide/kubectl/kubectl_rolling-update.md) in `kubectl`. +[rolling update](https://kubernetes.io/docs/user-guide/kubectl/kubectl_rolling-update.md#rolling-update) in `kubectl`. Complete execution flow can be found [here](#execution-details). See the -[example of rolling update](../user-guide/update-demo/) for more information. +[example of rolling update](https://kubernetes.io/docs/tutorials/kubernetes-basics/update-intro/) for more information. ### Lightweight rollout diff --git a/contributors/design-proposals/network/networking.md b/contributors/design-proposals/network/networking.md index 6540a567e..ff97aa833 100644 --- a/contributors/design-proposals/network/networking.md +++ b/contributors/design-proposals/network/networking.md @@ -127,7 +127,7 @@ to serve the purpose outside of GCE. ## Pod to service -The [service](../user-guide/services.md) abstraction provides a way to group pods under a +The [service](https://kubernetes.io/docs/concepts/services-networking/service/) abstraction provides a way to group pods under a common access policy (e.g. load-balanced). The implementation of this creates a virtual IP which clients can access and which is transparently proxied to the pods in a Service. Each node runs a kube-proxy process which programs diff --git a/contributors/design-proposals/scheduling/resources.md b/contributors/design-proposals/scheduling/resources.md index 27b69e87e..356f57e72 100644 --- a/contributors/design-proposals/scheduling/resources.md +++ b/contributors/design-proposals/scheduling/resources.md @@ -1,6 +1,6 @@ **Note: this is a design doc, which describes features that have not been completely implemented. User documentation of the current state is -[here](../user-guide/compute-resources.md). The tracking issue for +[here](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/). The tracking issue for implementation of this model is [#168](http://issue.k8s.io/168). Currently, both limits and requests of memory and cpu on containers (not pods) are supported. "memory" is in bytes and "cpu" is in milli-cores.** @@ -281,7 +281,7 @@ to encourage comments. Because resource usage and related metrics change continuously, need to be tracked over time (i.e., historically), can be characterized in a variety of ways, and are fairly voluminous, we will not include usage in core API objects, -such as [Pods](../user-guide/pods.md) and Nodes, but will provide separate APIs +such as [Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/) and Nodes, but will provide separate APIs for accessing and managing that data. See the Appendix for possible representations of usage data, but the representation we'll use is TBD.