If a namespace deletion is blocked, finding the reason why can require
reading the Conditions on the namespace.
Currently, `kubectl describe namespace` does not include Conditions.
This change adds Conditions to the output. Example output:
```
Name: example
Labels: <none>
Annotations: <none>
Status: Terminating
Conditions:
Type Status LastTransitionTime Reason Message
---- ------ ------------------ ------ -------
NamespaceDeletionContentFailure True Wed, 15 Jan 2014 00:00:00 +0000 example reason example message
No resource quota.
No LimitRange resource.
```
Kubernetes-commit: eb6e8ce00a39c1c98146f3341f4336b90757ab13
to keep a count of the pods that have the ready condition.
Also:
- Add feature gate JobReadyPods.
- Add Ready to describe.
Change-Id: Ib934730a430a8e2a2f485671e345fe2330006939
Kubernetes-commit: 1bff5eb44d9897e12aff3ea10f5a856580158278
* take into account new fields for event
* add event with old event fields for test
* fix: remove unnecessary "+1" from event series count
* fix: update the assertion for failing test case
Kubernetes-commit: c6935ad50e0809c1dc2d3ac9000abda0ecb49bcc
API returns unit format in a non deterministic manner; ie it
chooses a unit format according to a resource that gets counted first
Kubernetes-commit: 3f0b64ec9597488be6365f89cc82338bcb7a9feb
This change updates the CSR API to add a new, optional field called
expirationSeconds. This field is a request to the signer for the
maximum duration the client wishes the cert to have. The signer is
free to ignore this request based on its own internal policy. The
signers built-in to KCM will honor this field if it is not set to a
value greater than --cluster-signing-duration. The minimum allowed
value for this field is 600 seconds (ten minutes).
This change will help enforce safer durations for certificates in
the Kube ecosystem and will help related projects such as
cert-manager with their migration to the Kube CSR API.
Future enhancements may update the Kubelet to take advantage of this
field when it is configured in a way that can tolerate shorter
certificate lifespans with regular rotation.
Signed-off-by: Monis Khan <mok@vmware.com>
Kubernetes-commit: cd91e59f7c351fce47c064a5162c2cb79075159c
As discussed during the alpha review, the ReadOnly field is not really
needed because volume mounts can also be read-only. It's a historical
oddity that can be avoided for generic ephemeral volumes as part
of the promotion to beta.
Kubernetes-commit: 555d4a12bf58f19cbd79f866e2abce13490bde40
* api: structure change
* api: defaulting, conversion, and validation
* [FIX] validation: auto remove second ip/family when service changes to SingleStack
* [FIX] api: defaulting, conversion, and validation
* api-server: clusterIPs alloc, printers, storage and strategy
* [FIX] clusterIPs default on read
* alloc: auto remove second ip/family when service changes to SingleStack
* api-server: repair loop handling for clusterIPs
* api-server: force kubernetes default service into single stack
* api-server: tie dualstack feature flag with endpoint feature flag
* controller-manager: feature flag, endpoint, and endpointSlice controllers handling multi family service
* [FIX] controller-manager: feature flag, endpoint, and endpointSlicecontrollers handling multi family service
* kube-proxy: feature-flag, utils, proxier, and meta proxier
* [FIX] kubeproxy: call both proxier at the same time
* kubenet: remove forced pod IP sorting
* kubectl: modify describe to include ClusterIPs, IPFamilies, and IPFamilyPolicy
* e2e: fix tests that depends on IPFamily field AND add dual stack tests
* e2e: fix expected error message for ClusterIP immutability
* add integration tests for dualstack
the third phase of dual stack is a very complex change in the API,
basically it introduces Dual Stack services. Main changes are:
- It pluralizes the Service IPFamily field to IPFamilies,
and removes the singular field.
- It introduces a new field IPFamilyPolicyType that can take
3 values to express the "dual-stack(mad)ness" of the cluster:
SingleStack, PreferDualStack and RequireDualStack
- It pluralizes ClusterIP to ClusterIPs.
The goal is to add coverage to the services API operations,
taking into account the 6 different modes a cluster can have:
- single stack: IP4 or IPv6 (as of today)
- dual stack: IPv4 only, IPv6 only, IPv4 - IPv6, IPv6 - IPv4
* [FIX] add integration tests for dualstack
* generated data
* generated files
Co-authored-by: Antonio Ojea <aojea@redhat.com>
Kubernetes-commit: 6675eba3eff1c8e565c4060a9c1396f75da7cc3e
Empty key and non-empty effect means to match all keys and values and
the specified effect. However "kubectl describe" prints it without space
between effect and operator. This patch adds the space for this case.
Kubernetes-commit: 04185f4e533b9b8ebaabe1ed09516e85c5ed1ae1
NetworkPolicy egress-all `kubectl describe` output should refer
to the term "destination" as opposed to "source" for describing
policies which do not restrict traffic based on the destination.
Kubernetes-commit: e0caf0b46f061c3fafa10aef83592fe300f2bf52
This reuses the code for describing a PVC, except that the output gets
indented more and some fields are skipped.
Kubernetes-commit: c1178bd925b54898e66cace37d35bf551380a75b
Ingressv1 Get is attempted for Ingresses and IngressClasses
and falls back to Ingressv1beta1 if there is a failure.
Signed-off-by: Christopher M. Luciano <cmluciano@us.ibm.com>
Kubernetes-commit: 31520ccb9b9a96acc4721b69ae231a6cbb74a503
An empty key with operator Exists matches all keys, values
and effects which means this will tolerate everything:
tolerations:
- operator: "Exists"
as stated in https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/.
However, the current printTolerationsMultilineWithIndent implementation ignores
this case. As the toleration is valid, there's no reason
to skip it when writing the list of all pod's tolerations.
Kubernetes-commit: 0bd9a4c6c5ba4fbbc8439effddc99004ddd6b232
When I describe network policies, it often tells me that pods are
isolated for egress connectivity because the policy that applies to them
has no egress rules. However, this would only lead to isolation if there
is an explicitly set egress policy type. Otherwise, the policy allows
egress traffic. The same applies if you have explicitly set an egress
type only, describe will incorrectly report isolated ingress traffic.
This PR fixes this by inferring the applicable direction for the policy
based on the PolicyTypes, and then if a policy doesn't apply eg to
egress, we print 'Not affecting egress traffic'
Kubernetes-commit: 7753bfa3a418d95795420d03193732e024456466
The tool golangci-lint gives a bunch of warnings. This PR solves the easier/less controversial ones, so the code is simpler and a little bit more optimal, since it removes some if conditions.
Kubernetes-commit: cd2adbe760641f844d84d411f9adcf17fb6982ff
`Get` method within the fake clientset returns an object that would not be normally returned when using the real clientset. Reproducer:
```go
package main
import (
v1 "k8s.io/api/core/v1"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
"k8s.io/client-go/kubernetes/fake"
)
func main () {
cm := &v1.ConfigMap{
ObjectMeta: metav1.ObjectMeta{Namespace: metav1.NamespaceSystem, Name: "cm"},
}
client := fake.NewSimpleClientset(cm)
obj, err := client.CoreV1().ConfigMaps("").Get("", metav1.GetOptions{})
if err != nil {
panic(err)
}
fmt.Printf("obj: %#v\n", obj)
}
```
stored under `test.go` of `github.com/kubernetes/kubernetes` (master HEAD) root directory and ran:
```sh
$ go run test.go
obj: &v1.ConfigMap{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:v1.ObjectMeta{Name:"cm", GenerateName:"", Namespace:"kube-system", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Finalizers:[]string(nil), ClusterName:"", ManagedFields:[]v1.ManagedFieldsEntry(nil)}, Data:map[string]string(nil), BinaryData:map[string][]uint8(nil)}
```
As you can see fake clientset with a "test" configmap is created. When getting the object through the clientset back, I intentionally set the object name to an empty string. I would expect to get an error saying config map "" was not found. However, I get "test" configmap instead.
Reason for that is inside implementation of `filterByNamespaceAndName` private function:
```go
func filterByNamespaceAndName(objs []runtime.Object, ns, name string) ([]runtime.Object, error) {
var res []runtime.Object
for _, obj := range objs {
acc, err := meta.Accessor(obj)
if err != nil {
return nil, err
}
if ns != "" && acc.GetNamespace() != ns {
continue
}
if name != "" && acc.GetName() != name {
continue
}
res = append(res, obj)
}
return res, nil
}
```
When `name` is empty, `name != "" && acc.GetName() != name` condition is false and thus `obj` is consider as a fit.
[1] https://github.com/kubernetes/client-go/blob/master/testing/fixture.go#L481-L493
Kubernetes-commit: d32c76fc03381784516c47cb1bf62ef932189afa
Marcus Puckett