diff --git a/access.md b/access.md index d2fe44ca3..92840f737 100644 --- a/access.md +++ b/access.md @@ -118,8 +118,8 @@ Pods configs should be largely portable between Org-run and hosted configuration # Design Related discussion: -- https://github.com/GoogleCloudPlatform/kubernetes/issues/442 -- https://github.com/GoogleCloudPlatform/kubernetes/issues/443 +- http://issue.k8s.io/442 +- http://issue.k8s.io/443 This doc describes two security profiles: - Simple profile: like single-user mode. Make it easy to evaluate K8s without lots of configuring accounts and policies. Protects from unauthorized users, but does not partition authorized users. @@ -176,7 +176,7 @@ Initially: Improvements: - Kubelet allocates disjoint blocks of root-namespace uids for each container. This may provide some defense-in-depth against container escapes. (https://github.com/docker/docker/pull/4572) - requires docker to integrate user namespace support, and deciding what getpwnam() does for these uids. -- any features that help users avoid use of privileged containers (https://github.com/GoogleCloudPlatform/kubernetes/issues/391) +- any features that help users avoid use of privileged containers (http://issue.k8s.io/391) ### Namespaces @@ -253,7 +253,7 @@ Policy objects may be applicable only to a single namespace or to all namespaces ## Accounting -The API should have a `quota` concept (see https://github.com/GoogleCloudPlatform/kubernetes/issues/442). A quota object relates a namespace (and optionally a label selector) to a maximum quantity of resources that may be used (see [resources design doc](resources.md)). +The API should have a `quota` concept (see http://issue.k8s.io/442). A quota object relates a namespace (and optionally a label selector) to a maximum quantity of resources that may be used (see [resources design doc](resources.md)). Initially: - a `quota` object is immutable. diff --git a/admission_control.md b/admission_control.md index b84b2543e..9245aa7d3 100644 --- a/admission_control.md +++ b/admission_control.md @@ -37,7 +37,7 @@ Documentation for other releases can be found at | Topic | Link | | ----- | ---- | -| Separate validation from RESTStorage | https://github.com/GoogleCloudPlatform/kubernetes/issues/2977 | +| Separate validation from RESTStorage | http://issue.k8s.io/2977 | ## Background diff --git a/command_execution_port_forwarding.md b/command_execution_port_forwarding.md index 1d319adf7..852e761e7 100644 --- a/command_execution_port_forwarding.md +++ b/command_execution_port_forwarding.md @@ -44,9 +44,9 @@ This describes an approach for providing support for: There are several related issues/PRs: -- [Support attach](https://github.com/GoogleCloudPlatform/kubernetes/issues/1521) -- [Real container ssh](https://github.com/GoogleCloudPlatform/kubernetes/issues/1513) -- [Provide easy debug network access to services](https://github.com/GoogleCloudPlatform/kubernetes/issues/1863) +- [Support attach](http://issue.k8s.io/1521) +- [Real container ssh](http://issue.k8s.io/1513) +- [Provide easy debug network access to services](http://issue.k8s.io/1863) - [OpenShift container command execution proposal](https://github.com/openshift/origin/pull/576) ## Motivation diff --git a/event_compression.md b/event_compression.md index ce8d1ad4e..b14d52061 100644 --- a/event_compression.md +++ b/event_compression.md @@ -38,7 +38,7 @@ This document captures the design of event compression. ## Background -Kubernetes components can get into a state where they generate tons of events which are identical except for the timestamp. For example, when pulling a non-existing image, Kubelet will repeatedly generate `image_not_existing` and `container_is_waiting` events until upstream components correct the image. When this happens, the spam from the repeated events makes the entire event mechanism useless. It also appears to cause memory pressure in etcd (see [#3853](https://github.com/GoogleCloudPlatform/kubernetes/issues/3853)). +Kubernetes components can get into a state where they generate tons of events which are identical except for the timestamp. For example, when pulling a non-existing image, Kubelet will repeatedly generate `image_not_existing` and `container_is_waiting` events until upstream components correct the image. When this happens, the spam from the repeated events makes the entire event mechanism useless. It also appears to cause memory pressure in etcd (see [#3853](http://issue.k8s.io/3853)). ## Proposal @@ -109,10 +109,10 @@ This demonstrates what would have been 20 separate entries (indicating schedulin ## Related Pull Requests/Issues - * Issue [#4073](https://github.com/GoogleCloudPlatform/kubernetes/issues/4073): Compress duplicate events - * PR [#4157](https://github.com/GoogleCloudPlatform/kubernetes/issues/4157): Add "Update Event" to Kubernetes API - * PR [#4206](https://github.com/GoogleCloudPlatform/kubernetes/issues/4206): Modify Event struct to allow compressing multiple recurring events in to a single event - * PR [#4306](https://github.com/GoogleCloudPlatform/kubernetes/issues/4306): Compress recurring events in to a single event to optimize etcd storage + * Issue [#4073](http://issue.k8s.io/4073): Compress duplicate events + * PR [#4157](http://issue.k8s.io/4157): Add "Update Event" to Kubernetes API + * PR [#4206](http://issue.k8s.io/4206): Modify Event struct to allow compressing multiple recurring events in to a single event + * PR [#4306](http://issue.k8s.io/4306): Compress recurring events in to a single event to optimize etcd storage * PR [#4444](https://github.com/GoogleCloudPlatform/kubernetes/pull/4444): Switch events history to use LRU cache instead of map diff --git a/identifiers.md b/identifiers.md index 9e2699936..7deff9e9a 100644 --- a/identifiers.md +++ b/identifiers.md @@ -33,7 +33,7 @@ Documentation for other releases can be found at # Identifiers and Names in Kubernetes -A summarization of the goals and recommendations for identifiers in Kubernetes. Described in [GitHub issue #199](https://github.com/GoogleCloudPlatform/kubernetes/issues/199). +A summarization of the goals and recommendations for identifiers in Kubernetes. Described in [GitHub issue #199](http://issue.k8s.io/199). ## Definitions diff --git a/principles.md b/principles.md index 23a203495..be3dff559 100644 --- a/principles.md +++ b/principles.md @@ -70,7 +70,7 @@ TODO: pluggability ## Bootstrapping -* [Self-hosting](https://github.com/GoogleCloudPlatform/kubernetes/issues/246) of all components is a goal. +* [Self-hosting](http://issue.k8s.io/246) of all components is a goal. * Minimize the number of dependencies, particularly those required for steady-state operation. * Stratify the dependencies that remain via principled layering. * Break any circular dependencies by converting hard dependencies to soft dependencies. diff --git a/resources.md b/resources.md index e006d44d0..fe6f0ec76 100644 --- a/resources.md +++ b/resources.md @@ -33,7 +33,7 @@ Documentation for other releases can be found at **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 implementation of this model is -[#168](https://github.com/GoogleCloudPlatform/kubernetes/issues/168). Currently, only memory and +[#168](http://issue.k8s.io/168). Currently, only memory and cpu limits on containers (not pods) are supported. "memory" is in bytes and "cpu" is in milli-cores.** @@ -134,7 +134,7 @@ The following resource types are predefined ("reserved") by Kubernetes in the `k * Units: Kubernetes Compute Unit seconds/second (i.e., CPU cores normalized to a canonical "Kubernetes CPU") * Internal representation: milli-KCUs * Compressible? yes - * Qualities: this is a placeholder for the kind of thing that may be supported in the future — see [#147](https://github.com/GoogleCloudPlatform/kubernetes/issues/147) + * Qualities: this is a placeholder for the kind of thing that may be supported in the future — see [#147](http://issue.k8s.io/147) * [future] `schedulingLatency`: as per lmctfy * [future] `cpuConversionFactor`: property of a node: the speed of a CPU core on the node's processor divided by the speed of the canonical Kubernetes CPU (a floating point value; default = 1.0). diff --git a/secrets.md b/secrets.md index 3adc57af6..350d151b1 100644 --- a/secrets.md +++ b/secrets.md @@ -119,7 +119,7 @@ which consumes this type of secret, the Kubelet may take a number of actions: file system 2. Configure that node's `kube-proxy` to decorate HTTP requests from that pod to the `kubernetes-master` service with the auth token, e. g. by adding a header to the request - (see the [LOAS Daemon](https://github.com/GoogleCloudPlatform/kubernetes/issues/2209) proposal) + (see the [LOAS Daemon](http://issue.k8s.io/2209) proposal) #### Example: service account consumes docker registry credentials @@ -263,11 +263,11 @@ the right storage size for their installation and configuring their Kubelets cor Configuring each Kubelet is not the ideal story for operator experience; it is more intuitive that the cluster-wide storage size be readable from a central configuration store like the one proposed -in [#1553](https://github.com/GoogleCloudPlatform/kubernetes/issues/1553). When such a store +in [#1553](http://issue.k8s.io/1553). When such a store exists, the Kubelet could be modified to read this configuration item from the store. When the Kubelet is modified to advertise node resources (as proposed in -[#4441](https://github.com/GoogleCloudPlatform/kubernetes/issues/4441)), the capacity calculation +[#4441](http://issue.k8s.io/4441)), the capacity calculation for available memory should factor in the potential size of the node-level tmpfs in order to avoid memory overcommit on the node. diff --git a/security_context.md b/security_context.md index 7a80c01d2..4704caab2 100644 --- a/security_context.md +++ b/security_context.md @@ -42,7 +42,7 @@ A security context is a set of constraints that are applied to a container in or ## Background -The problem of securing containers in Kubernetes has come up [before](https://github.com/GoogleCloudPlatform/kubernetes/issues/398) and the potential problems with container security are [well known](http://opensource.com/business/14/7/docker-security-selinux). Although it is not possible to completely isolate Docker containers from their hosts, new features like [user namespaces](https://github.com/docker/libcontainer/pull/304) make it possible to greatly reduce the attack surface. +The problem of securing containers in Kubernetes has come up [before](http://issue.k8s.io/398) and the potential problems with container security are [well known](http://opensource.com/business/14/7/docker-security-selinux). Although it is not possible to completely isolate Docker containers from their hosts, new features like [user namespaces](https://github.com/docker/libcontainer/pull/304) make it possible to greatly reduce the attack surface. ## Motivation