mirror of
https://github.com/k3s-io/kubernetes.git
synced 2025-09-06 11:42:14 +00:00
Add ga-beacon analytics to gendocs scripts
hack/run-gendocs.sh puts ga-beacon analytics link into all md files, hack/verify-gendocs.sh verifies presence of link.
This commit is contained in:
Jeff Lowdermilk
@@ -15,3 +15,6 @@ A single Kubernetes cluster is not intended to span multiple availability zones.
|
||||
Finally, Kubernetes aspires to be an extensible, pluggable, building-block OSS platform and toolkit. Therefore, architecturally, we want Kubernetes to be built as a collection of pluggable components and layers, with the ability to use alternative schedulers, controllers, storage systems, and distribution mechanisms, and we're evolving its current code in that direction. Furthermore, we want others to be able to extend Kubernetes functionality, such as with higher-level PaaS functionality or multi-cluster layers, without modification of core Kubernetes source. Therefore, its API isn't just (or even necessarily mainly) targeted at end users, but at tool and extension developers. Its APIs are intended to serve as the foundation for an open ecosystem of tools, automation systems, and higher-level API layers. Consequently, there are no "internal" inter-component APIs. All APIs are visible and available, including the APIs used by the scheduler, the node controller, the replication-controller manager, Kubelet's API, etc. There's no glass to break -- in order to handle more complex use cases, one can just access the lower-level APIs in a fully transparent, composable manner.
|
||||
|
||||
For more about the Kubernetes architecture, see [architecture](architecture.md).
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -246,3 +246,6 @@ Initial implementation:
|
||||
Improvements:
|
||||
- API server does logging instead.
|
||||
- Policies to drop logging for high rate trusted API calls, or by users performing audit or other sensitive functions.
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -77,3 +77,6 @@ will ensure the following:
|
||||
6. Object is persisted
|
||||
|
||||
If at any step, there is an error, the request is canceled.
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -130,3 +130,6 @@ In the current proposal, the **LimitRangeItem** matches purely on **LimitRangeIt
|
||||
It is expected we will want to define limits for particular pods or containers by name/uid and label/field selector.
|
||||
|
||||
To make a **LimitRangeItem** more restrictive, we will intend to add these additional restrictions at a future point in time.
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -151,3 +151,6 @@ replicationcontrollers 5 20
|
||||
resourcequotas 1 1
|
||||
services 3 5
|
||||
```
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -42,3 +42,6 @@ The scheduler binds unscheduled pods to nodes via the `/binding` API. The schedu
|
||||
All other cluster-level functions are currently performed by the Controller Manager. For instance, `Endpoints` objects are created and updated by the endpoints controller, and nodes are discovered, managed, and monitored by the node controller. These could eventually be split into separate components to make them independently pluggable.
|
||||
|
||||
The [`replicationController`](../replication-controller.md) is a mechanism that is layered on top of the simple [`pod`](../pods.md) API. We eventually plan to port it to a generic plug-in mechanism, once one is implemented.
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -58,3 +58,6 @@ This diagram dynamic clustering using the bootstrap API endpoint. That API endp
|
||||
This flow has the admin manually approving the kubelet signing requests. This is the `queue` policy defined above.This manual intervention could be replaced by code that can verify the signing requests via other means.
|
||||
|
||||
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -23,4 +23,6 @@ If you are using boot2docker and get warnings about clock skew (or if things are
|
||||
|
||||
## Automatically rebuild on file changes
|
||||
|
||||
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`.
|
||||
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`.
|
||||
|
||||
[]()
|
||||
|
||||
@@ -141,4 +141,6 @@ functionality. We need to make sure that users are not allowed to execute
|
||||
remote commands or do port forwarding to containers they aren't allowed to
|
||||
access.
|
||||
|
||||
Additional work is required to ensure that multiple command execution or port 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.
|
||||
Additional work is required to ensure that multiple command execution or port 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.
|
||||
|
||||
[]()
|
||||
|
||||
@@ -76,3 +76,6 @@ This demonstrates what would have been 20 separate entries (indicating schedulin
|
||||
* 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
|
||||
* PR [#4444](https://github.com/GoogleCloudPlatform/kubernetes/pull/4444): Switch events history to use LRU cache instead of map
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -88,3 +88,6 @@ objectives.
|
||||
1. Each container is started up with enough metadata to distinguish the pod from whence it came.
|
||||
2. Each attempt to run a container is assigned a UID (a string) that is unique across time.
|
||||
1. This may correspond to Docker's container ID.
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -332,4 +332,6 @@ has a deletion timestamp and that its list of finalizers is empty. As a result,
|
||||
content associated from that namespace has been purged. It performs a final DELETE action
|
||||
to remove that Namespace from the storage.
|
||||
|
||||
At this point, all content associated with that Namespace, and the Namespace itself are gone.
|
||||
At this point, all content associated with that Namespace, and the Namespace itself are gone.
|
||||
|
||||
[]()
|
||||
|
||||
@@ -106,3 +106,6 @@ Another approach could be to create a new host interface alias for each pod, if
|
||||
### IPv6
|
||||
|
||||
IPv6 would be a nice option, also, but we can't depend on it yet. Docker support is in progress: [Docker issue #2974](https://github.com/dotcloud/docker/issues/2974), [Docker issue #6923](https://github.com/dotcloud/docker/issues/6923), [Docker issue #6975](https://github.com/dotcloud/docker/issues/6975). Additionally, direct ipv6 assignment to instances doesn't appear to be supported by major cloud providers (e.g., AWS EC2, GCE) yet. We'd happily take pull requests from people running Kubernetes on bare metal, though. :-)
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -212,3 +212,6 @@ cluster/kubectl.sh delete pvc myclaim-1
|
||||
The ```PersistentVolumeClaimBinder``` will reconcile this by removing the claim reference from the PV and change the PVs status to 'Released'.
|
||||
|
||||
Admins can script the recycling of released volumes. Future dynamic provisioners will understand how a volume should be recycled.
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -53,3 +53,6 @@ TODO
|
||||
## General principles
|
||||
|
||||
* [Eric Raymond's 17 UNIX rules](https://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond.E2.80.99s_17_Unix_Rules)
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -558,3 +558,6 @@ source. Both containers will have the following files present on their filesyst
|
||||
|
||||
/etc/secret-volume/username
|
||||
/etc/secret-volume/password
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -115,3 +115,6 @@ Both the Kubelet and Kube Proxy need information related to their specific roles
|
||||
The controller manager for Replication Controllers and other future controllers act on behalf of a user via delegation to perform automated maintenance on Kubernetes resources. Their ability to access or modify resource state should be strictly limited to their intended duties and they should be prevented from accessing information not pertinent to their role. For example, a replication controller needs only to create a copy of a known pod configuration, to determine the running state of an existing pod, or to delete an existing pod that it created - it does not need to know the contents or current state of a pod, nor have access to any data in the pods attached volumes.
|
||||
|
||||
The Kubernetes pod scheduler is responsible for reading data from the pod to fit it onto a minion in the cluster. At a minimum, it needs access to view the ID of a pod (to craft the binding), its current state, any resource information necessary to identify placement, and other data relevant to concerns like anti-affinity, zone or region preference, or custom logic. It does not need the ability to modify pods or see other resources, only to create bindings. It should not need the ability to delete bindings unless the scheduler takes control of relocating components on failed hosts (which could be implemented by 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).
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -155,3 +155,6 @@ has defined capabilities or privileged. Contexts that attempt to define a UID o
|
||||
will be denied by default. In the future the admission plugin will base this decision upon
|
||||
configurable policies that reside within the [service account](https://github.com/GoogleCloudPlatform/kubernetes/pull/2297).
|
||||
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -162,3 +162,6 @@ to services in the same namespace and read-write access to events in that namesp
|
||||
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.
|
||||
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
@@ -89,3 +89,6 @@ then ```foo-next``` is synthesized using the pattern ```<controller-name>-<hash-
|
||||
* Otherwise, ```foo-next``` and ```foo``` both exist
|
||||
* Set ```desired-replicas``` annotation on ```foo``` to match the annotation on ```foo-next```
|
||||
* Goto Rollout with ```foo``` and ```foo-next``` trading places.
|
||||
|
||||
|
||||
[]()
|
||||
|
||||
Reference in New Issue
Block a user