- 22 May, 2017 1 commit
-
-
Cao Shufeng authored
This change validate oidc flags for kube-apiserver.
-
- 21 May, 2017 7 commits
-
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue fix typo **What this PR does / why we need it**: **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes # **Special notes for your reviewer**: **Release note**: ```release-note ```
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue fix pleg relist time This PR fix pleg reslist time. According to current implementation, we have a `Healthy` method periodically check the relist time. If current timestamp subtracts latest relist time is longer than `relistThreshold`(default is 3 minutes), we should return an error to indicate the error of runtime. `relist` method is also called periodically. If runtime(docker) hung, the relist method should return immediately without updating the latest relist time. If we update latest relist time no matter runtime(docker) hung(default timeout is 2 minutes), the `Healthy` method will never return an error. ```release-note Kubelet PLEG updates the relist timestamp only after successfully relisting. ``` /cc @yujuhong @Random-Liu @dchen1107
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue Adapt loadbalancer deleting/updating when using cloudprovider openstack in openstack/liberty **What this PR does / why we need it**: Make an extra verification on the returned listeners and pools because gophercloud query doesn't filter the results by loadbalancerID / listenerID respectively when using **openstack/librerty**. **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes # #33759 **Special notes for your reviewer**: #33759 it's supposed to have a pull request which fixes this problem but in the release 1.5 loadbalancers doesn't use that patched code. **Release note**: NONE ```release-note ```
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue Bump e2e netexec pod.xml image version to 1.7 Changing the image version from 1.5 to 1.7
-
zhengjiajin authored
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue Move the remaining controllers to shared informers Completes work done in 1.6 to move the last two hold outs to shared informers - tokens controller and scheduler. Adds a few more tools to allow informer reuse (like filtering the informer, or maintaining a mutation cache). The mutation cache is identical to #45838 and will be removed when that merges @ncdc @deads2k extracted from openshift/origin#14086
-
Clayton Coleman authored
-
- 20 May, 2017 32 commits
-
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue [Federation][kubefed]: Move server image definition to cmd This enables consumers like openshift to provide a different default without editing the kubefed init logic. cc: @kubernetes/sig-federation-pr-reviews
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue Prepare for periodic runner Rerevert https://github.com/kubernetes/kubernetes/pull/46004 with the fix. For now, built on top of #45816
-
Clayton Coleman authored
Previously, the scheduler created two separate list watchers. This changes the scheduler to be able to leverage a shared informer, whether passed in externally or spawned using the new in place method. This removes the last use of a "special" informer in the codebase. Allows someone wrapping the scheduler to use a shared informer if they have more information avaliable.
-
Clayton Coleman authored
Tokens controller previously needed a bit of extra help in order to be safe for concurrent use. The new MutationCache allows it to keep a local cache and still use a shared informer. The filtering event handler lets it only see changes to secrets it cares about.
-
Clayton Coleman authored
Allows tokens controller to observe updates
-
Clayton Coleman authored
Allows an informer consumer to easily filter a set of changes out, possibly to maintain a smaller cache or to only operate on a known set of objects.
-
Clayton Coleman authored
-
Clayton Coleman authored
For reuse
-
Clayton Coleman authored
-
Clayton Coleman authored
Removes the spawning of goroutines in the cache (which could be a hotspot for anything in the critical path) as well.
-
Clayton Coleman authored
Will be used by client-go as well
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue Add protobuf binary version of OpenAPI spec Fixes #45833 Partially fixes #42841 ```release-note OpenAPI spec is now available in protobuf binary and gzip format (with ETag support) ```
-
Wojciech Tyczynski authored
-
Wojciech Tyczynski authored
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue Change kube-proxy so that we won't perform no-op calls
-
Wojciech Tyczynski authored
-
Wojciech Tyczynski authored
-
Wojciech Tyczynski authored
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue kube-apiserver: check upgrade header to detect upgrade connections Without this every connection with "Connection" header but without upgrade request are rejected. A simple curl will set "Connection", but does not intent to upgrade.
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue (batch tested with PRs 46014, 46152) Updated test/test_owners.csv for federation test cases To the best of my knowledge have updated the test owners for federation e2e test cases. PTAL and comment if any concern. **Release note**: ```release-note NONE ``` cc @kubernetes/sig-federation-pr-reviews @fejta /assign @madhusudancs
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue (batch tested with PRs 46014, 46152) format reads arg 3, have only 2 args, add i Signed-off-by:yupengzte <yu.peng36@zte.com.cn> **What this PR does / why we need it**: **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes # **Special notes for your reviewer**: **Release note**: ```release-note ```
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue (batch tested with PRs 46033, 46122, 46053, 46018, 45981) Command tree and exported env in kubectl plugins This is part of `kubectl` plugins V1: - Adds support to several env vars passing context information to the plugin. Plugins can make use of them to connect to the REST API, access global flags, get the path of the plugin caller (so that `kubectl` can be invoked) and so on. Exported env vars include - `KUBECTL_PLUGINS_DESCRIPTOR_*`: the plugin descriptor fields - `KUBECTL_PLUGINS_GLOBAL_FLAG_*`: one for each global flag, useful to access namespace, context, etc - ~`KUBECTL_PLUGINS_REST_CLIENT_CONFIG_*`: one for most fields in `rest.Config` so that a REST client can be built.~ - `KUBECTL_PLUGINS_CALLER`: path to `kubectl` - `KUBECTL_PLUGINS_CURRENT_NAMESPACE`: namespace in use - Adds support for plugins as child of other plugins so that a tree of commands can be built (e.g. `kubectl myplugin list`, `kubectl myplugin add`, etc) **Release note**: ```release-note Added support to a hierarchy of kubectl plugins (a tree of plugins as children of other plugins). Added exported env vars to kubectl plugins so that plugin developers have access to global flags, namespace, the plugin descriptor and the full path to the caller binary. ``` @kubernetes/sig-cli-pr-reviews
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue (batch tested with PRs 46033, 46122, 46053, 46018, 45981) ineffectual assignment to baseCommand, delete it Signed-off-by:yupengzte <yu.peng36@zte.com.cn> **What this PR does / why we need it**: **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes # **Special notes for your reviewer**: **Release note**: ```release-note ```
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue (batch tested with PRs 46033, 46122, 46053, 46018, 45981) Log age of stats used for evictions during eviction tests I recently added prometheus metrics for the age of the metrics used for evictions #43031. It would be nice to surface these during eviction tests, so I can better assess how old stats are, and whether or not the age of stats causes extra evictions. This isnt super-high priority, and can be done after code-freeze, since it is a testing improvement. Feel free to take a look whenever either of you has time. /assign @mtaufen /assign @Random-Liu
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue (batch tested with PRs 46033, 46122, 46053, 46018, 45981) Restore kube-proxy --version Accidentally removed by #34727. Fixes #46026
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue Reduce memory allocations in kube proxy Memory allocation (and Go GarbageCollection) seems to be one of the most expensive operations in kube-proxy (I've seen profiles where it was more than 50%). The commits are mostly independent from each other and all of them are mostly about reusing already allocated memory. This PR is reducing memory allocation by ~5x (results below from 100-node load test): before: ``` (pprof) top 38.64GB of 39.11GB total (98.79%) Dropped 249 nodes (cum <= 0.20GB) Showing top 10 nodes out of 61 (cum >= 0.20GB) flat flat% sum% cum cum% 15.10GB 38.62% 38.62% 15.10GB 38.62% bytes.makeSlice 9.48GB 24.25% 62.87% 9.48GB 24.25% runtime.rawstringtmp 8.30GB 21.21% 84.07% 32.47GB 83.02% k8s.io/kubernetes/pkg/proxy/iptables.(*Proxier).syncProxyRules 2.08GB 5.31% 89.38% 2.08GB 5.31% fmt.(*fmt).padString 1.90GB 4.86% 94.24% 3.82GB 9.77% strings.Join 0.67GB 1.72% 95.96% 0.67GB 1.72% runtime.hashGrow 0.36GB 0.92% 96.88% 0.36GB 0.92% runtime.stringtoslicebyte 0.31GB 0.79% 97.67% 0.62GB 1.58% encoding/base32.(*Encoding).EncodeToString 0.24GB 0.62% 98.29% 0.24GB 0.62% strings.genSplit 0.20GB 0.5% 98.79% 0.20GB 0.5% runtime.convT2E ``` after: ``` 7.94GB of 8.13GB total (97.75%) Dropped 311 nodes (cum <= 0.04GB) Showing top 10 nodes out of 65 (cum >= 0.11GB) flat flat% sum% cum cum% 3.32GB 40.87% 40.87% 8.05GB 99.05% k8s.io/kubernetes/pkg/proxy/iptables.(*Proxier).syncProxyRules 2.85GB 35.09% 75.95% 2.85GB 35.09% runtime.rawstringtmp 0.60GB 7.41% 83.37% 0.60GB 7.41% runtime.hashGrow 0.31GB 3.76% 87.13% 0.31GB 3.76% runtime.stringtoslicebyte 0.28GB 3.43% 90.56% 0.55GB 6.80% encoding/base32.(*Encoding).EncodeToString 0.19GB 2.29% 92.85% 0.19GB 2.29% strings.genSplit 0.18GB 2.17% 95.03% 0.18GB 2.17% runtime.convT2E 0.10GB 1.28% 96.31% 0.71GB 8.71% runtime.mapassign 0.10GB 1.21% 97.51% 0.10GB 1.21% syscall.ByteSliceFromString 0.02GB 0.23% 97.75% 0.11GB 1.38% syscall.SlicePtrFromStrings ``` -
Kubernetes Submit Queue authored
Automatic merge from submit-queue (batch tested with PRs 45346, 45903, 45958, 46042, 45975) examples/podsecuritypolicy/rbac: allow to use projected volumes in restricted PSP **What this PR does / why we need it**: This PR modifies `restricted` PSP to allow `projected` volume type. No need to modify `privileged` PSP because it already allows all volume types. It should not add any harm because `projected` uses configmaps, downward API, and secrets that are already permitted. **Special notes for your reviewer**: This was inspired by similar change in the OpenShift: https://github.com/openshift/origin/pull/14147 **Release note**: ```release-note NONE ``` PTAL @pweil- @derekwaynecarr CC @mfojtik
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue (batch tested with PRs 45346, 45903, 45958, 46042, 45975) ResourceQuota admission control injects registry **What this PR does / why we need it**: The `ResourceQuota` admission controller works with a registry that maps a GroupKind to an Evaluator. The registry used in the existing plug-in is not injectable, which makes usage of the ResourceQuota plug-in in other API server contexts difficult. This PR updates the code to support late injection of the registry via a plug-in initializer.
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue (batch tested with PRs 45346, 45903, 45958, 46042, 45975) Ignored mirror pods in PodPreset admission plugin **What this PR does / why we need it**: Ignored mirror pods in PodPreset admission plugin. **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #45925 **Release note**: ```release-note Ignored mirror pods in PodPreset admission plugin. ```
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue (batch tested with PRs 45346, 45903, 45958, 46042, 45975) Azure disk api This is to update the AzureDiskApi and split it from the implementation which is caught in rebase hell... Once this is merged, we'll get the implementation in. @smarterclayton suggested this as a way to break the rebase hell logjam. request for a quick review. Thanks!
-
Kubernetes Submit Queue authored
Automatic merge from submit-queue Don't try to attach volumes which are already attached to other nodes This PR is a replacement for https://github.com/kubernetes/kubernetes/pull/40148. I was not able to push fixes and rebases to the original branch as I don't have access to the Github organization anymore. CC @saad-ali You probably have to update the PR link in [Q2 2017 (v1.7)](https://docs.google.com/spreadsheets/d/1t4z5DYKjX2ZDlkTpCnp18icRAQqOE85C1T1r2gqJVck/edit#gid=14624465) I assume the PR will need a new "ok to test" **ORIGINAL PR DESCRIPTION** This PR fixes an issue with the attach/detach volume controller. There are cases where the `desiredStateOfWorld` contains the same volume for multiple nodes, resulting in the attach/detach controller attaching this volume to multiple nodes. This of course fails for volumes like AWS EBS, Azure Disks, ... I observed this situation on Azure when using Azure Disks and replication controllers which start to reschedule PODs. When you delete a POD that belongs to a RC, the RC will immediately schedule a new POD on another node. This results in a short time (max a few seconds) where you have 2 PODs which try to attach/mount the same volume on different nodes. As the old POD is still alive, the attach/detach controller does not try to detach the volume and starts to attach the volume to the new POD immediately. This behavior was probably not noticed before on other clouds as the bogus attempt to attach probably fails pretty fast and thus is unnoticed. As the situation with the 2 PODs disappears after a few seconds, a detach for the old POD is initiated and thus the new POD can attach successfully. On Azure however, attaching and detaching takes quite long, resulting in the first bogus attach attempt to already eat up much time. When attaching fails on Azure and reports that it is already attached somewhere else, the cloud provider immediately does a detach call for the same volume+node it tried to attach to. This is done to make sure the failed attach request is aborted immediately. You can find this here: https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/azure/azure_storage.go#L74 The complete flow of attach->fail->abort eats up valuable time and the attach/detach controller can not proceed with other work while this is happening. This means, if the old POD disappears in the meantime, the controller can't even start the detach for the volume which delays the whole process of rescheduling and reattaching. Also, I and other people have observed very strange behavior where disks ended up being "attached" to multiple VMs at the same time as reported by Azure Portal. This results in the controller to fail reattaching forever. It's hard to figure out why and when this happens and there is no reproducer known yet. I can imagine however that the described behavior correlates with what I described above. I was not sure if there are actually cases where it is perfectly fine to have a volume mounted to multiple PODs/nodes. At least technically, this should be possible with network based volumes, e.g. nfs. Can someone with more knowledge about volumes help me here? I may need to add a check before skipping attaching in `reconcile`. CC @colemickens @rootfs --> ```release-note Don't try to attach volume to new node if it is already attached to another node and the volume does not support multi-attach. ```
-
shashidharatd authored
-