kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #1332 from guineveresaenger/docfix 

Automatic merge from submit-queue.

removed deprecated munge script instructions

There is no `hack/update-munge-docs.sh` script. Documentation should not refer to it.
This commit is contained in:
Kubernetes Submit Queue 2017-11-08 17:42:23 -08:00 committed by GitHub
parent 7bdec391d2 a6dcf8678b
commit 930ce65595
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
175 changed files with 5 additions and 1009 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
contributors/design-proposals/README.md
View File

@ -9,7 +9,3 @@ Note that a number of these documents are historical and may be out of date or u
TODO: Add the current status to each document and clearly indicate which are up to date.
TODO: Document the [proposal process](../devel/faster_reviews.md#1-dont-build-a-cathedral-in-one-pr).
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/README.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/api-machinery/admission_control.md
View File

@ -99,8 +99,3 @@ following:
- If operation=connect, exec
If at any step, there is an error, the request is canceled.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/admission_control.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

7
contributors/design-proposals/api-machinery/admission_control_extension.md
View File

@ -632,9 +632,4 @@ Some options:
It should be easy for a novice Kubernetes administrator to apply simple policy rules to the cluster. In
the future it is desirable to have many such policy engines enabled via extension to enable quick policy
customization to meet specific needs.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/admission_control_extension.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->
customization to meet specific needs.

5
contributors/design-proposals/api-machinery/aggregated-api-servers.md
View File

@ -268,8 +268,3 @@ There were other alternatives that we had discussed.
providing a centralised authentication and authorization service which all of
the servers can use.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/aggregated-api-servers.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/api-machinery/api-chunking.md
View File

@ -175,8 +175,3 @@ The initial chunking implementation would focus on consistent listing on server
For the initial alpha release, chunking would be behind a feature flag and attempts to provide the `continue` or `limit` flags should be ignored. While disabled, a `continue` token should never be returned by the server as part of a list.
Future work might offer more options for clients to page in an inconsistent fashion, or allow clients to directly specify the parts of the namespace / name keyspace they wish to range over (paging).
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/server-get.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/api-machinery/api-group.md
View File

@ -113,7 +113,3 @@ To expose a list of the supported Openshift groups to clients, OpenShift just ha
## Future work
1. Dependencies between groups: we need an interface to register the dependencies between groups. It is not our priority now as the use cases are not clear yet.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/api-group.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/api-machinery/apiserver-watch.md
View File

@ -137,8 +137,3 @@ the same time, we can introduce an additional etcd event type: EtcdResync
However, this might turn out to be unnecessary optimization if apiserver
will always keep up (which is possible in the new design). We will work
out all necessary details at that point.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/apiserver-watch.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/api-machinery/auditing.md
View File

@ -374,7 +374,3 @@ Below are the possible future extensions to the auditing mechanism:
* Define how filters work. They should enable dropping sensitive fields from the request/response/storage objects.
* Allow setting a unique identifier which allows matching audit events across apiserver and federated servers.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/sysctl.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

7
contributors/design-proposals/api-machinery/client-package-structure.md
View File

@ -1,5 +1,3 @@
<!-- BEGIN MUNGE: GENERATED_TOC -->
- [Client: layering and package structure](#client-layering-and-package-structure)
- [Desired layers](#desired-layers)
- [Transport](#transport)
@ -12,7 +10,6 @@
- [Package Structure](#package-structure)
- [Client Guarantees (and testing)](#client-guarantees-and-testing)
<!-- END MUNGE: GENERATED_TOC -->
# Client: layering and package structure
@ -310,7 +307,3 @@ that client will not have to change their code until they are deliberately
upgrading their import. We probably will want to generate some sort of stub test
with a clientset, to ensure that we don't change the interface.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/client-package-structure.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/api-machinery/controller-ref.md
View File

@ -415,7 +415,3 @@ Summary of significant revisions to this document:
* Specify ControllerRef-related behavior changes upon upgrade/downgrade.
* [Implementation](#implementation)
* List all work to be done and mark items already completed as of this edit.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/controller-ref.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/api-machinery/event_compression.md
View File

@ -162,8 +162,3 @@ compressing multiple recurring events in to a single event.
single event to optimize etcd storage.
* PR [#4444](http://pr.k8s.io/4444): Switch events history to use LRU cache
instead of map.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/event_compression.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/api-machinery/extending-api.md
View File

@ -196,8 +196,3 @@ Thus, listing a third-party resource can be achieved by listing the directory:
```
${standard-k8s-prefix}/third-party-resources/${third-party-resource-namespace}/${third-party-resource-name}/${resource-namespace}/
```
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/extending-api.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

6
contributors/design-proposals/api-machinery/garbage-collection.md
View File

@ -349,9 +349,3 @@ In case the garbage collector is mistakenly deleting objects, we should provide
* Before an object is deleted from the registry, the API server clears fields like DeletionTimestamp, then creates the object in /archive and sets a TTL.
* Add a `kubectl restore` command, which takes a resource/name pair as input, creates the object with the spec stored in the /archive, and deletes the archived object.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/garbage-collection.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/api-machinery/metadata-policy.md
View File

@ -130,8 +130,3 @@ single scheduler, as opposed to choosing a scheduler, a desire mentioned in
`MetadataPolicy` could be used. Issue #17324 proposes to create a generalized
API for matching "claims" to "service classes"; matching a pod to a scheduler
would be one use for such an API.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/metadata-policy.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/api-machinery/protobuf.md
View File

@ -473,8 +473,3 @@ The generated protobuf will be checked with a verify script before merging.
## Open Questions
* Is supporting stored protobuf files on disk in the kubectl client worth it?
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/protobuf.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/api-machinery/server-get.md
View File

@ -177,7 +177,3 @@ fall back to client side functions.
Server side code would reuse the existing display functions but replace TabWriter with either a structured writer
or the tabular form.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/server-get.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

6
contributors/design-proposals/api-machinery/synchronous-garbage-collection.md
View File

@ -1,5 +1,4 @@
**Table of Contents**
<!-- BEGIN MUNGE: GENERATED_TOC -->
- [Overview](#overview)
- [API Design](#api-design)
@ -14,7 +13,6 @@
- [Unhandled cases](#unhandled-cases)
- [Implications to existing clients](#implications-to-existing-clients)
<!-- END MUNGE: GENERATED_TOC -->
# Overview
@ -169,7 +167,3 @@ To make the new kubectl compatible with the 1.4 and earlier masters, kubectl nee
1.4 `kubectl delete rc/rs` uses `DeleteOptions.OrphanDependents=true`, which is going to be converted to `DeletePropagationBackground` (see [API Design](#api-changes)) by a 1.5 master, so its behavior keeps the same.
Pre 1.4 `kubectl delete` uses `DeleteOptions.OrphanDependents=nil`, so does the 1.4 `kubectl delete` for resources other than rc and rs. The option is going to be converted to `DeletePropagationDefault` (see [API Design](#api-changes)) by a 1.5 master, so these commands behave the same as when working with a 1.4 master.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/synchronous-garbage-collection.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/apps/OBSOLETE_templates.md
View File

@ -562,8 +562,3 @@ Openshift handles template processing via a server endpoint which consumes a tem
produced by processing the template. It is also possible to handle the entire template processing flow via the client, but this was deemed
undesirable as it would force each client tool to reimplement template processing (e.g. the standard CLI tool, an eclipse plugin, a plugin for a CI system like Jenkins, etc). The assumption in this proposal is that server side template processing is the preferred implementation approach for
this reason.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/templates.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/apps/cronjob.md
View File

@ -333,7 +333,3 @@ Below are the possible future extensions to the Job controller:
happening in [#18827](https://issues.k8s.io/18827).
* Be able to specify more general template in `.spec` field, to create arbitrary
types of resources. This relates to the work happening in [#18215](https://issues.k8s.io/18215).
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/cronjob.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/apps/daemon.md
View File

@ -201,7 +201,3 @@ restartPolicy set to Always.
- Should work similarly to [Deployment](http://issues.k8s.io/1743).
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/daemon.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

7
contributors/design-proposals/apps/deploy.md
View File

@ -1,5 +1,3 @@
<!-- BEGIN MUNGE: GENERATED_TOC -->
- [Deploy through CLI](#deploy-through-cli)
- [Motivation](#motivation)
- [Requirements](#requirements)
@ -16,7 +14,6 @@
- [Pause Deployments](#pause-deployments)
- [Perm-failed Deployments](#perm-failed-deployments)
<!-- END MUNGE: GENERATED_TOC -->
# Deploy through CLI
@ -141,7 +138,3 @@ Users sometimes need to temporarily disable a deployment. See issue [#14516](htt
### Perm-failed Deployments
The deployment could be marked as "permanently failed" for a given spec hash so that the system won't continue thrashing on a doomed deployment. The users can retry a failed deployment with `kubectl rollout retry`. See issue [#14519](https://github.com/kubernetes/kubernetes/issues/14519).
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/deploy.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/apps/deployment.md
View File

@ -257,8 +257,3 @@ Apart from the above, we want to add support for the following:
- https://github.com/kubernetes/kubernetes/issues/1743 has most of the
discussion that resulted in this proposal.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/deployment.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/apps/indexed-job.md
View File

@ -894,7 +894,3 @@ is verbose. For StatefulSet, this is less of a problem.
This differs from StatefulSet in that StatefulSet uses names and not indexes. StatefulSet is
intended to support ones to tens of things.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/indexed-job.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/apps/job.md
View File

@ -206,7 +206,3 @@ Below are the possible future extensions to the Job controller:
by providing pointers to Pods in the JobStatus ([see comment](https://github.com/kubernetes/kubernetes/pull/11746/files#r37142628)).
* help users avoid non-unique label selectors ([see this proposal](../../docs/design/selector-generation.md))
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/job.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/apps/selector-generation.md
View File

@ -174,7 +174,3 @@ Docs will be edited to show examples without a `job.spec.selector`.
We probably want as much as possible the same behavior for Job and
ReplicationController.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/selector-generation.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

6
contributors/design-proposals/apps/stateful-apps.md
View File

@ -355,9 +355,3 @@ Requested features:
StatefulSets were formerly known as PetSets and were renamed to be less "cutesy" and more descriptive as a
prerequisite to moving to beta. No animals were harmed in the making of this proposal.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/stateful-apps.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/architecture/architecture.md
View File

@ -246,7 +246,3 @@ itself:
A single Kubernetes cluster may span multiple availability zones.
However, for the highest availability, we recommend using [cluster federation](../multicluster/federation.md).
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/architecture.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/architecture/identifiers.md
View File

@ -107,7 +107,3 @@ from whence it came.
unique across time.
1. This may correspond to Docker's container ID.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/identifiers.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/architecture/namespaces.md
View File

@ -363,8 +363,3 @@ storage.
At this point, all content associated with that Namespace, and the Namespace
itself are gone.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/namespaces.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/architecture/principles.md
View File

@ -96,7 +96,3 @@ TODO
* [Eric Raymond's 17 UNIX rules](https://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond.E2.80.99s_17_Unix_Rules)
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/principles.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/auth/access.md
View File

@ -370,7 +370,3 @@ Improvements:
- Policies to drop logging for high rate trusted API calls, or by users
performing audit or other sensitive functions.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/access.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

8
contributors/design-proposals/auth/apparmor.md
View File

@ -1,5 +1,3 @@
<!-- BEGIN MUNGE: GENERATED_TOC -->
- [Overview](#overview)
- [Motivation](#motivation)
- [Related work](#related-work)
@ -22,8 +20,6 @@
- [Profile authoring](#profile-authoring)
- [Appendix](#appendix)
<!-- END MUNGE: GENERATED_TOC -->
# Overview
AppArmor is a [mandatory access control](https://en.wikipedia.org/wiki/Mandatory_access_control)
@ -304,7 +300,3 @@ documentation for following this process in a Kubernetes environment.
```
$ apparmor_parser --remove /path/to/profile
```
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/apparmor.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/auth/enhance-pluggable-policy.md
View File

@ -422,8 +422,3 @@ type LocalResourceAccessReviewResponse struct {
Groups []string
}
```
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/enhance-pluggable-policy.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/auth/image-provenance.md
View File

@ -324,8 +324,3 @@ Additionally, just sending all the fields of just the Pod kind also has problems
- because we do not know which fields of an object are inspected by the backend, caching of decisions is not effective. Sending fewer fields allows caching.
- sending fewer fields makes it possible to rev the version of the webhook request slower than the version of our internal objects (e.g. pod v2 could still use imageReview v1.)
probably lots more reasons.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/image-provenance.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/auth/pod-security-context.md
View File

@ -368,7 +368,3 @@ E2E test cases will be added to test the correct determination of the security c
1. The Kubelet will use the new fields on the `PodSecurityContext` for host namespace control
2. The Kubelet will be modified to correctly implement the backward compatibility and effective
security context determination defined here
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/pod-security-context.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/auth/secrets.md
View File

@ -622,7 +622,3 @@ on their filesystems:
/etc/secret-volume/username
/etc/secret-volume/password
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/secrets.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/auth/security.md
View File

@ -212,7 +212,3 @@ a separate component that can delete bindings but not create them). The
scheduler may need read access to user or project-container information to
determine preferential location (underspecified at this time).
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/security.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/auth/security_context.md
View File

@ -186,7 +186,3 @@ privileged. Contexts that attempt to define a UID or SELinux options will be
denied by default. In the future the admission plugin will base this decision
upon configurable policies that reside within the [service account](http://pr.k8s.io/2297).
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/security_context.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/auth/service_accounts.md
View File

@ -204,7 +204,3 @@ Finally, it may provide an interface to automate creation of new
serviceAccounts. In that case, the user may want to GET serviceAccounts to see
what has been created.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/service_accounts.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

7
contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md
View File

@ -254,10 +254,3 @@ autoscaler to create a new pod. Discussed in issue [#3247](https://github.com/k
* *[future]* **When scaling down, make more educated decision which pods to
kill.** E.g.: if two or more pods from the same replication controller are on
the same node, kill one of them. Discussed in issue [#4301](https://github.com/kubernetes/kubernetes/issues/4301).
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/horizontal-pod-autoscaler.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/autoscaling/hpa-v2.md
View File

@ -285,7 +285,3 @@ come from the [custom metrics API](custom-metrics-api.md), which is
an adapter API which sources metrics directly from the monitoring
pipeline.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/hpa-v2.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

3
contributors/design-proposals/autoscaling/initial-resources.md
View File

@ -70,6 +70,3 @@ and should be introduced shortly after the first version is done:
* add estimation as annotations for those containers that already has resources set
* support for other data sources like [Hawkular](http://www.hawkular.org/)
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/initial-resources.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/aws/aws_under_the_hood.md
View File

@ -303,8 +303,3 @@ These scripts are responsible for mounting and formatting volumes, downloading
Salt and Kubernetes from the S3 bucket, and then triggering Salt to actually
install Kubernetes.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/aws_under_the_hood.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

33
contributors/design-proposals/cli/kubectl-extension.md
View File

@ -1,36 +1,3 @@
<!-- BEGIN MUNGE: UNVERSIONED_WARNING -->
<!-- BEGIN STRIP_FOR_RELEASE -->
<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
width="25" height="25">
<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
width="25" height="25">
<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
width="25" height="25">
<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
width="25" height="25">
<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
width="25" height="25">
<h2>PLEASE NOTE: This document applies to the HEAD of the source tree</h2>
If you are using a released version of Kubernetes, you should
refer to the docs that go with that version.
<!-- TAG RELEASE_LINK, added by the munger automatically -->
<strong>
The latest release of this document can be found
[here](http://releases.k8s.io/release-1.3/docs/proposals/kubectl-extension.md).
Documentation for other releases can be found at
[releases.k8s.io](http://releases.k8s.io).
</strong>
--
<!-- END STRIP_FOR_RELEASE -->
<!-- END MUNGE: UNVERSIONED_WARNING -->
# Kubectl Extension

4
contributors/design-proposals/cli/kubectl-login.md
View File

@ -214,7 +214,3 @@ Phase 2:
Further improvements will require adding more authentication providers, and
adapting existing plugins to take advantage of challenge based authentication.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/kubectl-login.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/cli/kubectl_apply_getsetdiff_last_applied_config.md
View File

@ -190,7 +190,3 @@ instead of by the configuration.
4. Verify the last-applied-config has been updated
- `kubectl apply view-last-applied -f deployment_nginx.yaml`
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/configmap.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/cli/simple-rolling-update.md
View File

@ -124,8 +124,3 @@ rollout with the old version
* Set `desired-replicas` annotation on `foo` to match the annotation on
`foo-next`
* Goto Rollout with `foo` and `foo-next` trading places.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/simple-rolling-update.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/cloud-provider/cloud-provider-refactoring.md
View File

@ -161,8 +161,3 @@ Release 1.9: All of the legacy cloud providers will be completely removed in thi
* Cloud specific operations will be moved out of kube-apiserver using the external admission controller pattern mentioned above.
* All cloud specific volume controller loops (attach, detach, provision operation controllers) will be switched to using flex volumes. Flex volumes do not need in-tree cloud specific calls.
* As the final step, all of the cloud provider specific code will be moved out of tree.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/cloud-provider-refactoring.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md
View File

@ -242,7 +242,3 @@ The binding of the `system:bootstrappers` (or similar) group to the ability to s
- Initial proposal ([@jbeda](https://github.com/jbeda)): [link](https://github.com/kubernetes/community/blob/cb9f198a0763e0a7540cdcc9db912a403ab1acab/contributors/design-proposals/bootstrap-discovery.md)
- v1.6 updates ([@jbeda](https://github.com/jbeda)): [link](https://github.com/kubernetes/community/blob/d8ce9e91b0099795318bb06c13f00d9dad41ac26/contributors/design-proposals/bootstrap-discovery.md)
- v1.8 updates ([@luxas](https://github.com/luxas))
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/super-simple-discovery-api.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/cluster-lifecycle/cluster-deployment.md
View File

@ -165,7 +165,3 @@ this by distributing deployment scripts via a docker image so that user will run
```docker run gcr.io/google_containers/deploy_kubernetes:v1.2 up --num-nodes=3 --provider=aws```
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/cluster-deployment.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/cluster-lifecycle/clustering.md
View File

@ -121,8 +121,3 @@ the `queue` policy defined above. This manual intervention could be replaced by
code that can verify the signing requests via other means.
![Dynamic Sequence Diagram](clustering/dynamic.png)
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/clustering.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/cluster-lifecycle/clustering/README.md
View File

@ -29,7 +29,3 @@ If you have the fswatch utility installed, you can have it monitor the file
system and automatically rebuild when files have changed. Just do a
`make watch`.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/clustering/README.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/cluster-lifecycle/dramatically-simplify-cluster-creation.md
View File

@ -259,8 +259,3 @@ It also doesn't require kubelet to do TLS bootstrapping - kubeadm handles that.
## See also
* [Joe Beda's "K8s the hard way easier"](https://docs.google.com/document/d/1lJ26LmCP-I_zMuqs6uloTgAnHPcuT7kOYtQ7XSgYLMA/edit#heading=h.ilgrv18sg5t) which combines Kelsey's "Kubernetes the hard way" with history of proposed UX at the end (scroll all the way down to the bottom).
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/dramatically-simplify-cluster-creation.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

3
contributors/design-proposals/cluster-lifecycle/ha_master.md
View File

@ -231,6 +231,3 @@ will be in the same version.
* Apiserver talks only to a local etcd replica which will be in a compatible version
* We assume we will introduce this setup after we upgrade to etcd v3 so we don't need to cover upgrading database.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/ha_master.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/cluster-lifecycle/high-availability.md
View File

@ -2,7 +2,3 @@
This document is deprecated. For more details about running a highly available
cluster master, please see the [admin instructions document](https://kubernetes.io/docs/admin/high-availability/).
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/high-availability.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/cluster-lifecycle/kubelet-tls-bootstrap.md
View File

@ -237,7 +237,3 @@ auth.
- supplemental policy (e.g. cluster CA only issues 30-day certs for hostnames *.k8s.example.com, each new cert must have fresh keys, ...)
- fully automated provisioning (using a handshake protocol or external list of authorized machines)
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/kubelet-tls-bootstrap.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md
View File

@ -154,8 +154,3 @@ minikube -> docker -> localkube
- The latest version of Minikube is guaranteed to support the latest release of Kubernetes, including documentation.
- The Google Cloud SDK will package minikube and provide utilities for configuring kubectl to use it, but will not in any other way wrap minikube.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/local-cluster-ux.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

3
contributors/design-proposals/cluster-lifecycle/runtimeconfig.md
View File

@ -64,6 +64,3 @@ APIs and not flags ([#12245](https://issues.k8s.io/12245)). When that is added,
could be handled by versioned component config and the component flags
deprecated.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/runtimeconfig.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/cluster-lifecycle/self-hosted-kubelet.md
View File

@ -128,8 +128,3 @@ register itself with a given taint when it first contacts the API server. Given
that, a kubelet could register itself with a given taint such as
“component=kubelet”, and a kubelet pod could exist that has a toleration to that
taint, ensuring it is the only pod the “bootstrap” kubelet runs.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/self-hosted-kubelet.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

6
contributors/design-proposals/instrumentation/core-metrics-pipeline.md
View File

@ -8,7 +8,6 @@
This document proposes a design for the set of metrics included in an eventual Core Metrics Pipeline.
<!-- BEGIN MUNGE: GENERATED_TOC -->
- [Core Metrics in kubelet](#core-metrics-in-kubelet)
- [Introduction](#introduction)
@ -23,7 +22,6 @@ This document proposes a design for the set of metrics included in an eventual C
- [On-Demand Design:](#on-demand-design)
- [Future Work](#future-work)
<!-- END MUNGE: GENERATED_TOC -->
## Introduction
@ -150,7 +148,3 @@ Suggested, tentative future work, which may be covered by future proposals:
- Decide on the format, name, and kubelet endpoint for publishing these metrics.
- Integrate with the CRI to allow compatibility with a greater number of runtimes, and to create a better runtime abstraction.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/core-metrics-pipeline.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/instrumentation/monitoring_architecture.md
View File

@ -196,8 +196,3 @@ Prometheus format.
![Architecture Diagram](monitoring_architecture.png?raw=true "Architecture overview")
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/monitoring_architecture.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/instrumentation/performance-related-monitoring.md
View File

@ -110,7 +110,3 @@ We should monitor other aspects of the system, which may indicate saturation of
Basic ideas:
- queue length for queues in the system,
- wait time for WaitGroups.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/performance-related-monitoring.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

3
contributors/design-proposals/instrumentation/resource-metrics-api.md
View File

@ -146,6 +146,3 @@ Depending on the further requirements the following features may be added:
- possibility to query for window sizes and aggregation functions (though single window size/aggregation function per request)
- cluster level metrics
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/resource-metrics-api.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

3
contributors/design-proposals/multi-platform.md
View File

@ -527,6 +527,3 @@ The 30th of November 2015, a tracking issue about making Kubernetes run on ARM w
The 27th of April 2016, Kubernetes `v1.3.0-alpha.3` was released, and it became the first release that was able to run the [docker getting started guide](http://kubernetes.io/docs/getting-started-guides/docker/) on `linux/amd64`, `linux/arm`, `linux/arm64` and `linux/ppc64le` without any modification.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/multi-platform.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/multicluster/control-plane-resilience.md
View File

@ -233,7 +233,3 @@ be automated and continuously tested.
</tr>
</table>
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/control-plane-resilience.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/multicluster/federated-api-servers.md
View File

@ -2,7 +2,3 @@
Moved to [aggregated-api-servers.md](../api-machinery/aggregated-api-servers.md) since cluster
federation stole the word "federation" from this effort and it was very confusing.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/federated-api-servers.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/multicluster/federated-ingress.md
View File

@ -188,7 +188,3 @@ Assuming that GCP-only (see above) is complete:
In theory the same approach as "Cross-cloud via GCP" above could be used, except that AWS infrastructure would be used to get traffic first to an AWS cluster, and then proxied onwards to non-AWS and/or on-prem clusters.
Detail docs TBD.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/federated-ingress.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/multicluster/federated-replicasets.md
View File

@ -506,8 +506,3 @@ target cluster, to watch changes in every target cluster etcd
regarding the posted LRS's and if any violation from the scheduled
number of replicase is detected the scheduling code is re-called for
re-scheduling purposes.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/federated-replicasets.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/multicluster/federated-services.md
View File

@ -513,7 +513,3 @@ state, and apply changes to the underlying kubernetes clusters accordingly. They
also have the anti-entropy mechanism for reconciling Cluster Federation "desired desired"
state against kubernetes "actual desired" state.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/federated-services.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/multicluster/federation-lite.md
View File

@ -195,7 +195,3 @@ Initially therefore, the GCE changes will be to:
1. change the kubernetes cloud provider to iterate through relevant zones when resolving items
1. tag GCE PD volumes with the appropriate zone information
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/federation-lite.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/multicluster/federation-phase-1.md
View File

@ -400,8 +400,3 @@ This part has been included in the section “Federated Service” of
document
“[Federated Cross-cluster Load Balancing and Service Discovery Requirements and System Design](federated-services.md))”.
Please refer to that document for details.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/federation-phase-1.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/multicluster/federation.md
View File

@ -641,8 +641,3 @@ does each replica find the other replicas and how do clients find
their primary zookeeper replica? And now how do I do a shared, highly
available redis database? Use a few common specific use cases like
this to flesh out the detailed API and semantics of Cluster Federation.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/federation.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/network/command_execution_port_forwarding.md
View File

@ -152,7 +152,3 @@ forwarding connections from different clients are not able to see each other's
data. This can most likely be achieved via SELinux labeling and unique process
contexts.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/command_execution_port_forwarding.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

3
contributors/design-proposals/network/external-lb-source-ip-preservation.md
View File

@ -1,5 +1,3 @@
<!-- BEGIN MUNGE: GENERATED_TOC -->
- [Overview](#overview)
- [Motivation](#motivation)
- [Alpha Design](#alpha-design)
@ -27,7 +25,6 @@
- [Future work](#future-work)
- [Appendix](#appendix)
<!-- END MUNGE: GENERATED_TOC -->
# Overview

4
contributors/design-proposals/network/flannel-integration.md
View File

@ -126,7 +126,3 @@ This proposal is really just a call for community help in writing a Kubernetes x
* Investigate flannel server running on every node (as done in the reference implementation mentioned above)
* Use flannel reservation mode to support node controller podcidr allocation
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/flannel-integration.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/network/network-policy.md
View File

@ -297,8 +297,3 @@ spec:
## References
- https://github.com/kubernetes/kubernetes/issues/22469 tracks network policy in kubernetes.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/network-policy.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/network/networking.md
View File

@ -186,7 +186,3 @@ AWS started rolling out basic
but direct ipv6 assignment to instances doesn't appear to be supported by other
major cloud providers (e.g. GCE) yet. We'd happily take pull requests from people
running Kubernetes on bare metal, though. :-)
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/networking.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

7
contributors/design-proposals/network/service-discovery.md
View File

@ -60,10 +60,3 @@ The fragment below is taken from the service section of the kubernetes.json were
Five service annotations are proposed as a standard way to describe a service endpoint. These five annotation are promoted as a Kubernetes standard, so that services can be discovered and a service catalog can be build to facilitate service consumers.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/service-discovery.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/network/service-external-name.md
View File

@ -154,8 +154,3 @@ result in a failure during server certificate validation. This is acknowledged
and left for future consideration. For the time being, users and administrators
might need to ensure that the server certificates also mentions the Kubernetes
name as an alternate host name.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/service-external-name.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/node/all-in-one-volume.md
View File

@ -299,8 +299,3 @@ spec:
path: my-group/my-password
mode: 511
```
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/all-in-one-volume.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

3
contributors/design-proposals/node/annotations-downward-api.md
View File

@ -62,6 +62,3 @@ env:
In general, this environment downward API part will be implemented in the same
place as the other metadata - as a label conversion function.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/annotations-downward-api.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/node/configmap.md
View File

@ -294,7 +294,3 @@ spec:
In the future, we may add the ability to specify an init-container that can
watch the volume contents for updates and respond to changes when they occur.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/configmap.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/node/container-init.md
View File

@ -438,7 +438,3 @@ master and Kubelet is tracked in issue [#4855](https://github.com/kubernetes/kub
* Unify pod QoS class with init containers
* Implement container / image volumes to make composition of runtime from images efficient
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/container-init.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/node/container-runtime-interface-v1.md
View File

@ -260,8 +260,3 @@ can potentially become a very thin daemon.
* Metrics: [#27097](https://issues.k8s.io/27097)
* Log management: [#24677](https://issues.k8s.io/24677)
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/container-runtime-interface-v1.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/node/disk-accounting.md
View File

@ -580,8 +580,3 @@ Capacity in MB = 1638400 * 512 * 128 bytes = 100 GB
* If you use a non-default location for docker storage, change `/var/lib/docker` in the examples to your storage location.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/disk-accounting.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/node/downward_api_resources_limits_requests.md
View File

@ -616,7 +616,3 @@ and
export GOMAXPROCS=$(CPU_LIMIT)"
```
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/downward_api_resources_limits_requests.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

3
contributors/design-proposals/node/dynamic-kubelet-configuration.md
View File

@ -308,6 +308,3 @@ There is discussion in [#10179](https://github.com/kubernetes/kubernetes/issues/
+ Reconciling configuration with objects added after the completion of a rollout, e.g. new `Nodes`.
+ Pausing/resuming a rollout.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/dynamic-kubelet-settings.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/node/envvar-configmap.md
View File

@ -182,7 +182,3 @@ cm2_key2="b"
Add similar support for Secrets.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/envvar-configmap.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/node/expansion.md
View File

@ -410,8 +410,3 @@ spec:
value: "http://gitserver.$(POD_NAMESPACE):$(SERVICE_PORT)"
restartPolicy: Never
```
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/expansion.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

3
contributors/design-proposals/node/kubelet-auth.md
View File

@ -101,6 +101,3 @@ This mode allows any authenticated request.
* Add support for CRL revocation for x509 client certificate authentication (http://issue.k8s.io/18982)
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/kubelet-auth.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/node/kubelet-cri-logging.md
View File

@ -233,8 +233,3 @@ evolves.
[4] rkt support: https://github.com/systemd/systemd/pull/4179
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/kubelet-cri-logging.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/node/kubelet-eviction.md
View File

@ -463,8 +463,3 @@ for eviction. Instead `DaemonSet` should ideally include Guaranteed pods only.
The pod eviction may evict more pods than needed due to stats collection timing gap. This can be mitigated by adding
the ability to get root container stats on an on-demand basis (https://github.com/google/cadvisor/issues/1247) in the future.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/kubelet-eviction.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/node/kubelet-hypercontainer-runtime.md
View File

@ -38,8 +38,3 @@ runtime.
The HyperContainer runtime is maintained by <https://github.com/kubernetes/frakti>.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/kubelet-hypercontainer-runtime.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/node/kubelet-rkt-runtime.md
View File

@ -97,7 +97,3 @@ In the future, some of these decisions are expected to be changed such that rkt
5. Revendor rktlet into `pkg/kubelet/rktshim`, and start deprecating the `pkg/kubelet/rkt` package.
6. Eventually replace the current `pkg/kubelet/rkt` package.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/kubelet-rkt-runtime.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/node/kubelet-systemd.md
View File

@ -401,7 +401,3 @@ Some OS distributions will fix this bug in versions of docker <= 1.0.9, so opera
be aware of how their version of `docker` was packaged when using this feature.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/kubelet-systemd.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/node/node-allocatable.md
View File

@ -334,8 +334,3 @@ according to `KubeReserved`.
The community should be notified that an update to schedulers is recommended, but if a scheduler is
not updated it falls under the above case of "scheduler is not allocatable-resources aware".
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/node-allocatable.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/node/pod-lifecycle-event-generator.md
View File

@ -194,8 +194,3 @@ redundant syncs.
* Instruct pod workers to set up a wake-up call if syncing failed, so that
it can retry.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/pod-lifecycle-event-generator.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

5
contributors/design-proposals/node/pod-pid-namespace.md
View File

@ -70,8 +70,3 @@ to disable the shared PID namespace in the subsequent release.
[1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/pod-pid-namespace.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

4
contributors/design-proposals/node/propagation.md
View File

@ -309,7 +309,3 @@ These concerns are valid and we decide to limit the propagation mode to HostPath
volume only, in HostPath, we expect any runtime should NOT perform any additional
actions (such as clean up). This behavior is also consistent with current HostPath
logic: kube does not take care of the content in HostPath either.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/proposals/propagation.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

3
contributors/design-proposals/node/resource-qos.md
View File

@ -213,6 +213,3 @@ A strict hierarchy of user-specified numerical priorities is not desirable becau
1. Achieved behavior would be emergent based on how users assigned priorities to their pods. No particular SLO could be delivered by the system, and usage would be subject to gaming if not restricted administratively
2. Changes to desired priority bands would require changes to all user pod configurations.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/resource-qos.md?pixel)]()
<!-- END MUNGE: GENERATED_ANALYTICS -->

Some files were not shown because too many files have changed in this diff Show More