commit
496d7d455e
|
@ -20,7 +20,7 @@ On the Windows platform, processes may be assigned to a job object, which can ha
|
|||
[#547](https://github.com/kubernetes/features/issues/547)
|
||||
|
||||
## Motivation
|
||||
The goal is to start filling the gap of platform support in CRI, specifically for Windows platform. For example, currrently in dockershim Windows containers are scheduled using the default resource constraints and does not respect the resource requests and limits specified in POD. With this proposal, Windows containers will be able to leverage POD spec and CRI to allocate compute resource and respect restriction.
|
||||
The goal is to start filling the gap of platform support in CRI, specifically for Windows platform. For example, currently in dockershim Windows containers are scheduled using the default resource constraints and does not respect the resource requests and limits specified in POD. With this proposal, Windows containers will be able to leverage POD spec and CRI to allocate compute resource and respect restriction.
|
||||
|
||||
## Proposed design
|
||||
|
||||
|
|
|
@ -86,7 +86,7 @@ We propose that:
|
|||
|
||||
### Controller workflow for provisioning volumes
|
||||
|
||||
0. Kubernetes administator can configure name of a default StorageClass. This
|
||||
0. Kubernetes administrator can configure name of a default StorageClass. This
|
||||
StorageClass instance is then used when user requests a dynamically
|
||||
provisioned volume, but does not specify a StorageClass. In other words,
|
||||
`claim.Spec.Class == ""`
|
||||
|
|
|
@ -46,7 +46,7 @@ This proposal aims to improve DNS performance by running a dns caching agent on
|
|||
|
||||
## Motivation
|
||||
|
||||
* With the current DNS achitecture, it is possible that pods with the highest DNS QPS have to reach out to a different node, if there is no local kube-dns instance.
|
||||
* With the current DNS architecture, it is possible that pods with the highest DNS QPS have to reach out to a different node, if there is no local kube-dns instance.
|
||||
Having a local cache will help improve the latency in such scenarios.
|
||||
|
||||
* Skipping iptables DNAT and connection tracking will help reduce [conntrack races](https://github.com/kubernetes/kubernetes/issues/56903) and avoid UDP DNS entries filling up conntrack table.
|
||||
|
|
|
@ -8,7 +8,7 @@ To understand how this file is generated, see https://git.k8s.io/community/gener
|
|||
--->
|
||||
# Autoscaling Special Interest Group
|
||||
|
||||
Covers development and maintenance of componets for automated scaling in Kubernetes. This includes automated vertical and horizontal pod autoscaling, initial resource estimation, cluster-proportional system component autoscaling, and autoscaling of Kubernetes clusters themselves.
|
||||
Covers development and maintenance of components for automated scaling in Kubernetes. This includes automated vertical and horizontal pod autoscaling, initial resource estimation, cluster-proportional system component autoscaling, and autoscaling of Kubernetes clusters themselves.
|
||||
|
||||
## Meetings
|
||||
* Regular SIG Meeting: [Mondays at 14:00 UTC](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit) (biweekly/triweekly). [Convert to your timezone](http://www.thetimezoneconverter.com/?t=14:00&tz=UTC).
|
||||
|
|
|
@ -421,7 +421,7 @@ sigs:
|
|||
- name: Autoscaling
|
||||
dir: sig-autoscaling
|
||||
mission_statement: >
|
||||
Covers development and maintenance of componets for automated scaling in
|
||||
Covers development and maintenance of components for automated scaling in
|
||||
Kubernetes. This includes automated vertical and horizontal pod
|
||||
autoscaling, initial resource estimation, cluster-proportional system
|
||||
component autoscaling, and autoscaling of Kubernetes clusters themselves.
|
||||
|
|
Loading…
Reference in New Issue