kubernetes / enhancements Goto Github PK
View Code? Open in Web Editor NEWEnhancements tracking repo for Kubernetes
License: Apache License 2.0
Enhancements tracking repo for Kubernetes
License: Apache License 2.0
The idea is to add templated variables to ConfigMap values, so each time a ConfigMap is applied to a pod - it can transform the value into something specific to a pod. Right now the best example is pod IP address.
We assume that there are two possible variables that can be used to consume pod facts: pod.IP
and pod.name
, which evaluate to pod.Status.podIP
and pod.Name
.
Let's consider following ConfigMap:
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
service.ip: $(pod.IP)
other.value: trololo
service.name: $(pod.name)
Then we have a pod with a service that needs to put the IP of the pod in the config file /etc/config/service.ip
.
Pod manifest can look like that:
apiVersion: v1
kind: Pod
metadata:
name: pod-facts-consumer
spec:
containers:
- name: test-container
image: gcr.io/google_containers/busybox
command: [ "/bin/sh", "cat", "/etc/config/service.ip" ]
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: special-config
restartPolicy: Never
When we create above ConfigMap and run the pod, we expect the test-container
output to be an IP address that was assigned to the Pod.
The proof of concept implementation is demoed here: https://asciinema.org/a/e90cs3ymgtatdexk6rmjuet92
It uses the code from this fork/branch: https://github.com/nebril/kubernetes/tree/pod-facts-in-configmaps.
This feature will allow applications that need pod facts to be configured properly using just ConfigMaps. An example of such application can be Galera, which needs local IP addresses in my.conf
file.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Third party orchestrators can use a clean, swagger 2.0 based interface to interact with K8s, improving the ability to build k8s clients, and letting users use tools they are familiar with, and read up to date documentation. (includes + Swagger bug fixes). This description will be fleshed out by @lavalamp.
There are many planned improvements but we will treat them as bug fixes.
(lavalamp deleted all of the checkboxes that used to be here because they don't make any sense for this feature.)
/pkg/apis/...
)@kubernetes/api
@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/api
@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
@kubernetes/feature-reviewers
on this issue to get approval before checking this offFEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers
.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
@kubernetes/feature-reviewers
member, you can check this checkbox, and the reviewer will apply the "design-complete" label.Coding
@kubernetes/feature-reviewers
and they willDocs
@kubernetes/docs
.In v1.3, v1.4 of Cluster Federation, the Kubernetes v1.3 style authentication model is used. A single set of credentials per cluster is used by the federation control plane to access underlying clusters on behalf of all users of the federation. The underlying clusters have no idea who the federation user on behalf of whom the federation control plane is acting is.
In this enhancement, each federation user will be individually authenticated, authorized and tracked in underlying clusters.
/pkg/apis/...
)@kubernetes/api
@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/api
@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
@kubernetes/feature-reviewers
on this issue to get approval before checking this offFEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers
.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
@kubernetes/feature-reviewers
member, you can check this checkbox, and the reviewer will apply the "design-complete" label.Coding
@kubernetes/feature-reviewers
and they willDocs
@kubernetes/docs
.Simple config parameterization is an important tool for extending the utility of example config. This feature will add an API object that represents a set of standard parameters and a list of objects with replacement syntax, a minimal set of CLI commands that transform templates + parameters into a list of API objects, and an API endpoint that allow templates to be stored.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
use
verb in policy
API group (will need to allow via either group for some time period)EDITED by @dchen1107 on Sept 23, 2016
Currently, Docker (https://www.docker.com/) is the default container runtime used by Kubernetes. Kubernetes release quality is significantly affected by Docker release quality.
The container technology evolves very rapidly, and so does Docker. Kubernetes canβt stick with a specific Docker version because
Docker releases per month, and before each release there are also several pre-releases. To ensure Kubernetes compatible with new Docker release, every quarter we had to invest at least 2-week engineer time to manually validate Docker release quality. For example, for 1.3 Kubernetes release, Kubernetes engineer manually validated
but we still couldn't cover all Docker (pre)release.
Thus, we developed the automated docker validation framework. It is a framework automatically validates newest Docker (pre)release against Kubernetes HEAD everyday, the validation includes functionality validation and performance validation.
Thanks for wanting to add a feature to Kubernetes! You will be responsible for guiding
your feature through completion, and asking the right people for approvals.
Large features typically go through three stages: Alpha, Beta, and Stable
Each stage requires various approvals from various teams.
You can use the checkboxes below to
track your progress. You can delete the text above once you have read it. Please keep the checklist.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Add description here
/pkg/apis/...
)@kubernetes/api
@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/api
@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
@kubernetes/feature-reviewers
on this issue to get approval before checking this offFEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers
.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
@kubernetes/feature-reviewers
member, you can check this checkbox, and the reviewer will apply the "design-complete" label.Coding
@kubernetes/feature-reviewers
and they willDocs
@kubernetes/docs
.Make it possible to vary the resource limits on a pod over its lifetime. In particular, this is valuable for pets (i.e., pods that are very costly to destroy and re-create).
This was discussed in the Node SIG meeting of 12 July 2016, where it was noted that this is a big cross-cutting issue and that @ncdc might be an appropriate owner.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Add AppArmor support to Kubernetes. Initial support should include the ability to specify an AppArmor profile for a container or pod in the API, and have that profile applied by the container runtime.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: BETA
More advice:
Design
Coding
Docs
This feature was merged into v1.3 and is an alpha feature behind a flag. Creating a feature for tracking through the rest of the process.
etcd v3 is a new API supported by etcd v3.0.0+. There are a number advantages of this new API but there are a changes that need to happen both externally, like turning etcd v3 on by default and migration docs, and internally, like testing and continued storage improvements, to fully take advantage of etcd v3.
Why is this a feature? It slightly changes the operation of Kubernetes clusters and impacts SIG Scalabilities and SIG API Machinery work. This is already an alpha feature today that makes etcd v3 a non-default backend but there is work that remains to move from an alpha feature to a well tested complete feature.
FEATURE_STATUS: Stable
kubernetes/kubernetes#25634
kubernetes/kubernetes#26753
kubernetes/website#643
The Kubernetes project would love to collect information about how customers are using their clusters, to help us prioritize work. The initial version of this feature would be downloaded (separate from installation) and would report on a regular basis:
All data would be stripped of any PII before submission, and shared with the CNCF.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
As a user, I want to add my own nodes to Kubernetes, and make sure they meet the minimum requirements for running as a Kubernetes node so that I can use pre-approved images, and speed adding new compute. cc @yujuhong @dchen1107
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
This feature adds a way for users to control metadata tags on their containers. Each of the various container runtimes has a way to put some sort of user tag on containers. Giving users control over this is useful for scenarios in which the user wants to integrate Kubernetes with other platforms and facilities.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Developers have a single place where defaults should be coded, and kubectl doesn't need to roundtrip json before sending it to the apiserver
kubectl doesn't apply defaults or overwrite apiserver - the apiserver is the single place where defaults are intelligently created. cc @lavalamp
Kubernetes has "cluster addon pods" that provide system services but do not run on the master node. Some of them are critical to have fully functional cluster: Heapster, DNS, UI. Users can break their cluster by evicting a critical addon (either manually or as a side effect of an other operation like upgrade) which possibly can become pending (for example when the cluster is highly utilized). To avoid such situation we introduce a rescheduler component that runs on the master and guarantees that critical addons are scheduled assuming the cluster is big enough. It does this by watching for pending critical pods and evicting other pods to make room for the pending one(s).
Design Proposal: kubernetes/kubernetes#29195
FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
This feature aims at extending the current pod specification with support
for namespaced kernel parameters (sysctls) set for each pod.
FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
AppController will allow to work with statefull applications that involve many components (openstack for example) more easy and more native. AppController will understand dependencies between kubernetes objects and therefore it will create them in correct order.
kubernetes/kubernetes issue: kubernetes/kubernetes#29453
cc @kubernetes/sig-openstack @kubernetes/sig-apps
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Simplify setup for HA Master. Description in kubernetes/kubernetes#29649
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Building on the disk accounting in 1.3, handle out-of-disk and refactor intelligent disk management. Proposal will be fleshed out by @dchen1107 or assignee.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Add description here
/pkg/apis/...
)@kubernetes/api
@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/api
@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
@kubernetes/feature-reviewers
on this issue to get approval before checking this offFEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers
.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
@kubernetes/feature-reviewers
member, you can check this checkbox, and the reviewer will apply the "design-complete" label.Coding
@kubernetes/feature-reviewers
and they willDocs
@kubernetes/docs
.The API server should provide endpoints to allow access control checks and subject access checks without direct knowledge of the backing authorization engine. This allows delegation of authorization.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
batch/v1
kubernetes/kubernetes#102363batch/v1
kubernetes/kubernetes#101613batch/v1
kubernetes/kubernetes#99423Finish the federated services that have been completed in 1.3. This description is woefully incomplete and will be fleshed out/replaced by @quinton-hoole.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Organizations wish to avoid running "unapproved" images.
The exact nature of "approval" is beyond the scope of Kubernetes, but may include reasons like:
FEATURE_STATUS: Proposal review
Federated services that are not exposed on public IP's or public DNS names.
/pkg/apis/...
)@kubernetes/api
@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/api
@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
@kubernetes/feature-reviewers
on this issue to get approval before checking this offFEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers
.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
@kubernetes/feature-reviewers
member, you can check this checkbox, and the reviewer will apply the "design-complete" label.Coding
@kubernetes/feature-reviewers
and they willDocs
@kubernetes/docs
.Continue to refine the performance of the API server, controllers, and client infrastructure to achieve our scale goals (~5k nodes and 300k pods) on a single cluster. This involves continuous testing at scale and refinement of our core systems for efficiency, as well as scaling testing from many large deployments.
By the 1.4 release, we hope to identify major scale blockers between the current certified numbers and our target numbers and get much closer.
FEATURE_STATUS: ONGOING
Design
Coding
Docs
Currently, a Kubernetes Pod's containers are assumed to be Docker images (and to use Docker's discovery).
However, with the progress of the OCI Image Spec, the inclusion of the rkt runtime (which supports docker, OCI, and ACI images), it's clear that now is a good time to consider making it possible to run additional formats.
Existing discussion of this feature have already shown demand and intent to address it eventually, just not urgency.
Ref: An old proposal, a user's request, and a bit more discussion.
This issue could also relate to generalizing image transport (ref kubernetes/kubernetes#15484), but does not necessarily have to.
FEATURE_STATUS: PENDING
Note: This feature does not currently have a shepherd and it is likely it will not make the v1.4 milestone. I think tentatively marking it v1.5 and trying to get a shepherd and initial proposal a little before the v1.4 release would be a good thing to shoot for.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Creating a new Kubernetes cluster is too hard. We need to simplify the number and types of actions to get a production cluster up and running.
Note that this is different from bringing up a development cluster (single node ala monokube or minikube) or automation around cluster creation (https://github.com/kubernetes/community/wiki/Roadmap:-Cluster-Deployment).
If we do this right, the number of manual steps to get a cluster running should be minimal. This will have the added benefit of making other deployment scenarios (dev cluster, cluster automation) simpler and smaller.
As part of this, we should make simplifying assumptions and have opinionated defaults. An example would be embedding etcd and picking an easy to use network technology. Certificates and trust should be established automatically.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Currently add-on management is baked in kube-up.sh
and is subject to various kinds of issues. Current implementation lacks transparency, clear specification and any separation from other layers, among other more technical downsides. This part of the effort towards #11, and is a fairly easy one to tackle.
As discussed in kubernetes-retired/kubernetes-anywhere#126, it looks like a low-hanging fruit, and existing projects can be easily used to pave the way. More specifically, the assumption is that Helm should work pretty well for this, and only a thin layer of automation would be required to make it seamless.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
/pkg/apis/...
)@kubernetes/api
@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/api
@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
@kubernetes/feature-reviewers
on this issue to get approval before checking this offFEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers
.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
@kubernetes/feature-reviewers
member, you can check this checkbox, and the reviewer will apply the "design-complete" label.Coding
@kubernetes/feature-reviewers
and they willDocs
@kubernetes/docs
.As a user, I want to be able to spread workloads to multiple clusters spread across multiple failure domains to improve my application uptime.
(Note: This is just one use case for pod affinity/anti-affinity.)
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Provide ingress for multi-zone clusters. This description will be fleshed out by @quinton-hoole.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Design Doc: https://github.com/kubernetes/kubernetes/blob/master/docs/design/podaffinity.md
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Accessing Kubernetes resources from federation apiserver feature enables users to be able to get all or a subset of all their resources from all their Kubernetes clusters under federation by talking to federation Apiserver. Note that users will be able to get all resources from underlying clusters, not just the ones which have a corresponding federation object.
The design doc is in progress will be uploaded soon
/pkg/apis/...
)@kubernetes/api
@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/api
@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
@kubernetes/feature-reviewers
on this issue to get approval before checking this offFEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers
.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
@kubernetes/feature-reviewers
member, you can check this checkbox, and the reviewer will apply the "design-complete" label.Coding
@kubernetes/feature-reviewers
and they willDocs
@kubernetes/docs
.The use case for this new feature is a Kubernetes operator who is providing a multi-tenant service based on namespaces. Each namespace belongs to one tenant. One tenant should not have a view of the whole cluster; rather the tenant's view should be constricted properly.
There are a few facets to this problem. One of them is the DNS client configuration applied in the tenant's pods. The k8s API has an optional dnsPolicy
field in a PodSpec
, and that field's value can be either ClusterFirst
or Default
; the default behavior is that of ClusterFirst
. The Default
setting means that the pod uses its host's DNS client configuration. The ClusterFirst
setting means that the pod's DNS client configuration ignores the host's DNS client configuration and gives the pod only settings based on the kubelet arguments. The kubelet's --cluster-dns
parameter, if supplied, is prepended to the DNS server list. The domain search list is prepended by the kubelet's --cluster-domain
parameter if there is one, and then svc.cluster.local
cluster.local
(where the cluster.local
part can be varied by another kubelet parameter) unconditionally.
The idea in this proposal is to allow a namespace to override the behavior of the ClusterFirst
setting to make it mean that the stuff prepended comes from a new namespace field rather than kubelet parameters. We introduce into NamespaceSpec
an optional field dnsClientConfig
of a new type DNSClientConfig
. A DNSClientConfig
holds a list of DNS server addresses and a list of strings (search domains). If the dnsClientConfig
is present in a namespace then for every pod in that namespace the ClusterFirst
behavior is to derive the pod's DNS client config by prepending the contents of the namespace's DNSClientConfig
(rather than the settings derived from the kubelet parameters) to the config from the host.
/pkg/apis/...
)@kubernetes/api
@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/api
@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
@kubernetes/feature-reviewers
on this issue to get approval before checking this offFEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers
.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
@kubernetes/feature-reviewers
member, you can check this checkbox, and the reviewer will apply the "design-complete" label.Coding
@kubernetes/feature-reviewers
and they willDocs
@kubernetes/docs
.Add a subcommand to kubectl which can update kubeconfig auth providers configs (kubernetes/kubernetes#23066) and trigger login events. The initial implementation will add support for the OpenID Connect auth provider and a basic auth challenge.
Prior POC and discussion in kubernetes/kubernetes#25758
cc @kubernetes/sig-auth
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
We should separate image management, resource / cgroup management, logging management from today's runtime interface. After this effort, we effectively make today's runtime interface as pod / container lifecycle management interface. cc @yujuhong @dchen1107
Proposal here: kubernetes/kubernetes#25899
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Many of the existing (v1.4) federated API objects are by default scheduled across all underlying clusters (e.g. federated services, namespaces, secrets, ingress...). Federated replicasets support a set of alpha annotations by which the user can influence replica placement. This alpha concept is extended to a fully supported API for scheduling entities across multiple clusters and cloud providers.
The beginnings of a design proposal are here:
https://docs.google.com/document/d/1dbKS6banuv44eEUm4YLNvEI0lDa1dpI-Z1E4MWeEyxQ/edit?ts=58f4e60e
/pkg/apis/...
)@kubernetes/api
@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/api
@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
@kubernetes/feature-reviewers
on this issue to get approval before checking this offFEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers
.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
@kubernetes/feature-reviewers
member, you can check this checkbox, and the reviewer will apply the "design-complete" label.Coding
@kubernetes/feature-reviewers
and they willDocs
@kubernetes/docs
.There is ongoing work for Kubernetes' support of rkt as a production-ready, generally usable container runtime option. This project is sometimes called rktnetes. π
There has already been significant work to implement this feature, and as of v1.3 it's already a supported option. However, it does not yet have full feature parity with the default Docker runtime, and I would be wary of calling it "production ready".
In order to have a sane scope for this feature, I'd like for it to track the rkt container runtime having full support for all Kubernetes features, support in Kubernetes deployment, well documented, and a great production choice.
FEATURE_STATUS: IN_DEVELOPMENT (I'm not sure the right status; this has had an initial release suitable for use; development is being done to improve the integration and address known issues / caveats).
cc @kubernetes/sig-node
Short meta-note: This feature might or might not actually fit here since it's something that is and has been in progress for quite a while. Many of the bullet points don't work well for it because of its circumstances, and I'm hopeful that it can help refine this process a bit; I've taken some liberties with formatting.
As a cluster operator, I want the kubelet to monitor local disk usage and respond accordingly to maintain node stability. If the kubelet observes available disk and/or inodes (rootfs or imagefs) are under pressure, the kubelet should pro-actively reclaim related resource to maintain node stability by deleting images, logs, and evicting pods.
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
The current dynamic provisioning feature supports only a single provisioner per cluster. This feature will allow multiple provisioners to be configured in a single cluster.
/pkg/apis/...
)volume.alpha.kubernetes.io/storage-class
).
@kubernetes/docs
@kubernetes/feature-reviewers
on this issue to get approval before checking this offFEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
Services should be able to reference an external DNS address instead of only pods, which will allow application authors to reference services that exist off platform, on other clusters, or locally.
Owner @rata
/pkg/apis/...
)FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
Coding
Docs
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.