PV.Spec.CSI.*SecretReference.Name should be allowed to have up to be
limited to 253 characters (DNS1123Subdomain) and not to 63 characters
(DNS1123Label), so all possible Secrets names can be used as secrets in a
PV.
This is continuation of
https://github.com/kubernetes/kubernetes/pull/108331 / Kubernetes 1.25,
which allowed updating PVs with long secret names, if the previous PV had
long secret name too. This makes sure downgrade from 1.27 to 1.26 works well
and allows PVs created in 1.27 to be updated in 1.26.
Now the long secret names are accepted during PV creation too.
A recent commit changed name validation from DNS Subdomain to DNS Label.
The assumption was that a subdomain-named SS could never work and the
only reasonable thing to do would be to delete it. But if there is a
finalizer, the delete is not possible because we would reject the update
because the old name (subdomain) did not pass the new validation.
This commit does not re-validate the ObjectMeta on update. Probably
every resource should follow this pattern, but mostly it's a non-issue
becauase the above change (name validation) is not something we do -
this case was excpetional.
Any StatefuleSet which took advantage of this (by having dots in the
name) can't have worked because we set `pod.spec.hostname` from it,
which is validated as a DNS label.
So while this is strictly a breaking change, it doesn't break anything
that was not already broken.
Add generatod docs for batch v1
Start types with uppercase letters
Fix batch API docs under pgs/apis
Create generated files for batch v1
Fix batch v1beta1 docs
Generate new files after merge conflict
This is in response to review feedback. Checking for valid node names and the
set property catches programming mistakes in the components that have write
permission.
This adds a new resource.k8s.io API group with v1alpha1 as version. It contains
four new types: resource.ResourceClaim, resource.ResourceClass, resource.ResourceClaimTemplate, and
resource.PodScheduling.
Also make some design changes exposed in testing and review.
Do not remove the ambiguous old metric
`apiserver_flowcontrol_request_concurrency_limit` because reviewers
though it is too early. This creates a problem, that metric can not
keep both of its old meanings. I chose the configured concurrency
limit.
Testing has revealed a design flaw, which concerns the initialization
of the seat demand state tracking. The current design in the KEP is
as follows.
> Adjustment is also done on configuration change … For a newly
> introduced priority level, we set HighSeatDemand, AvgSeatDemand, and
> SmoothSeatDemand to NominalCL-LendableSD/2 and StDevSeatDemand to
> zero.
But this does not work out well at server startup. As part of its
construction, the APF controller does a configuration change with zero
objects read, to initialize its request-handling state. As always,
the two mandatory priority levels are implicitly added whenever they
are not read. So this initial reconfig has one non-exempt priority
level, the mandatory one called catch-all --- and it gets its
SmoothSeatDemand initialized to the whole server concurrency limit.
From there it decays slowly, as per the regular design. So for a
fairly long time, it appears to have a high demand and competes
strongly with the other priority levels. Its Target is higher than
all the others, once they start to show up. It properly gets a low
NominalCL once other levels show up, which actually makes it compete
harder for borrowing: it has an exceptionally high Target and a rather
low NominalCL.
I have considered the following fix. The idea is that the designed
initialization is not appropriate before all the default objects are
read. So the fix is to have a mode bit in the controller. In the
initial state, those seat demand tracking variables are set to zero.
Once the config-producing controller detects that all the default
objects are pre-existing, it flips the mode bit. In the later mode,
the seat demand tracking variables are initialized as originally
designed.
However, that still gives preferential treatment to the default
PriorityLevelConfiguration objects, over any that may be added later.
So I have made a universal and simpler fix: always initialize those
seat demand tracking variables to zero. Even if a lot of load shows
up quickly, remember that adjustments are frequent (every 10 sec) and
the very next one will fully respond to that load.
Also: revise logging logic, to log at numerically lower V level when
there is a change.
Also: bug fix in float64close.
Also, separate imports in some file
Co-authored-by: Han Kang <hankang@google.com>
so that it explicitly describe group information defined in the
container image will be kept. This also adds e2e test case of
SupplementalGroups with pre-defined groups in the container
image to make the behaivier clearer.
- New API field .spec.schedulingGates
- Validation and drop disabled fields
- Disallow binding a Pod carrying non-nil schedulingGates
- Disallow creating a Pod with non-nil nodeName and non-nil schedulingGates
- Adds a {type:PodScheduled, reason:WaitingForGates} condition if necessary
- New literal SchedulingGated in the STATUS column of `k get pod`
Removed the unit tests that test the cases when the MixedProtocolLBService feature flag was false - the feature flag is locked to true with GA
Added an integration test to test whether the API server accepts an LB Service with different protocols.
Added an e2e test to test whether a service which is exposed by a multi-protocol LB Service is accessible via both ports.
Removed the conditional validation that compared the new and the old Service definitions during an update - the feature flag is locked to true with GA.
This `DeploymentSpec` struct is used internally; the ones used for
serialization do have a pointer and this text was most likely copied
from there and not corrected.
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
Fixes instances of #98213 (to ultimately complete #98213 linting is
required).
This commit fixes a few instances of a common mistake done when writing
parallel subtests or Ginkgo tests (basically any test in which the test
closure is dynamically created in a loop and the loop doesn't wait for
the test closure to complete).
I'm developing a very specific linter that detects this king of mistake
and these are the only violations of it it found in this repo (it's not
airtight so there may be more).
In the case of Ginkgo tests, without this fix, only the last entry in
the loop iteratee is actually tested. In the case of Parallel tests I
think it's the same problem but maybe a bit different, iiuc it depends
on the execution speed.
Waiting for the CI to confirm the tests are still passing, even after
this fix - since it's likely it's the first time those test cases are
executed - they may be buggy or testing code that is buggy.
Another instance of this is in `test/e2e/storage/csi_mock_volume.go` and
is still failing so it has been left out of this commit and will be
addressed in a separate one
Introduce networking/v1alpha1 api group.
Add `ClusterCIDR` type to networking/v1alpha1 api group, this type
will enable the NodeIPAM controller to support multiple ClusterCIDRs.
This commit just adds a validation according to KEP-127. We check that
only the supported volumes for phase 1 of the KEP are accepted.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
It is used to request that a pod runs in a unique user namespace.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
Co-authored-by: Rodrigo Campos <rodrigoca@microsoft.com>
- PreemptionByKubeScheduler (Pod preempted by kube-scheduler)
- DeletionByTaintManager (Pod deleted by taint manager due to NoExecute taint)
- EvictionByEvictionAPI (Pod evicted by Eviction API)
- DeletionByPodGC (an orphaned Pod deleted by PodGC)PreemptedByScheduler (Pod preempted by kube-scheduler)
We now partly drop the support for seccomp annotations which is planned
for v1.25 as part of the KEP:
https://github.com/kubernetes/enhancements/issues/135
Pod security policies are not touched by this change and therefore we
have to keep the annotation key constants.
This means we only allow the usage of the annotations for backwards
compatibility reasons while the synchronization of the field to
annotation is no longer supported. Using the annotations for static pods
is also not supported any more.
Making the annotations fully non-functional will be deferred to a
future release.
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
- Run hack/update-codegen.sh
- Run hack/update-generated-device-plugin.sh
- Run hack/update-generated-protobuf.sh
- Run hack/update-generated-runtime.sh
- Run hack/update-generated-swagger-docs.sh
- Run hack/update-openapi-spec.sh
- Run hack/update-gofmt.sh
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
Refactor common validation into methods that validate a single container
and call these methods when iterating the three types of container
lists. Move initContainer-specific validation from validateContainers to
validateInitContainers.
This resolves issues where init and ephemeral containers would return
duplicate or incorrectly formatted errors for problems detected by
validateContainers.
Adds missing tests based on KUBE_COVER and checks that errors returned
by validation are of the type and for the field expected. Fixes tests
that had multiple errors so later failures aren't masked if there's
a regression in only one of the errors.
This introduces no changes to unit tests other than to switch from
map-based to struct-based tables in TestValidateContainers and
TestValidateInitContainers in order to make diffs for later commits
easier to read.
At present the CSI spec secret name validation for ControllerPublish,
ControllerExpand, NodePublish secrets are performed against
ValidateDNS1123Label() and it causes the secret name validation
inside the CSI spec to go wrong if the secret name is more than 63 chars.
Kubernetes allow the secret object name to be on `DNS SubDomainName`
and having a secret name length between 0-253 is correct/valid. So the CSI
spec validation also has to be performed accordingly.
This commit address this issue in validation for above mentioned funcs.
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
* restructure tests
restructure TestValidateStatefulSet and TestValidateStatefulSetUpdate to be an array and accept list of expected errors. in this commits, no tests were changed and expected errors are not filled yet
* add expected errors
adding expected errors and making the tests pass, without making any changes to the tests
* clean up TestValidateStatefulSet error cases
* clean up TestValidateStatefulSetUpdate cases
* validate new statefulset as part of update validation
* address PR comments
considering many PV sources exist today with secretRef fields
this introduce a secretRef validation function which could be
used based on the pv spec source type. There are different field
restrictions exist today for these PV types like some of them
dont need namespace reference..etc. The PV spec validation has
to be adjusted for different PVs, but this commit try to make
use of this newly introduced secretRef validation function for
CSI volume source.
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
CSI spec 1.5 enhanced the spec to add optional secrets field to
NodeExpandVolumeRequest. This commit adds NodeExpandSecret to the
CSI PV source and also derive the expansion secret in csiclient to
send it out as part of the nodeexpand request.
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
Signed-off-by: zhucan <zhucan.k8s@gmail.com>
* Introduce networking/v1alpha1 api, ClusterCIDRConfig type
Introduce networking/v1alpha1 api group.
Add `ClusterCIDRConfig` type to networking/v1alpha1 api group, this type
will enable the NodeIPAM controller to support multiple ClusterCIDRs.
* Change ClusterCIDRConfig.NodeSelector type in api
* Fix review comments for API
* Update ClusterCIDRConfig API Spec
Introduce PerNodeHostBits field, remove PerNodeMaskSize
* Add FeatureGate PodHostIPs
* Add HostIPs field and update PodIPs field
* Types conversion
* Add dropDisabledStatusFields
* Add HostIPs for kubelet
* Add fuzzer for PodStatus
* Add status.hostIPs in ConvertDownwardAPIFieldLabel
* Add status.hostIPs in validEnvDownwardAPIFieldPathExpressions
* Downward API support for status.hostIPs
* Add DownwardAPI validation for status.hostIPs
* Add e2e to check that hostIPs works
* Add e2e to check that Downward API works
* Regenerate
Default to enabled
Fix validation of null-updates/patches when the "old" PVC was persisted by
an older version. Add upgrade integration tests written by liggitt.
Remove the comment "As of v1.22, this field is beta and is controlled
via the CSRDuration feature gate" from the expirationSeconds field's
godoc.
Mark the "CSRDuration" feature gate as GA in 1.24, lock its value to
"true", and remove the various logic which handled when the gate was
"false".
Update conformance test to check that the CertificateSigningRequest's
Spec.ExpirationSeconds field is stored, but do not check if the field
is honored since this functionality is optional.
- Lock feature gate to true and schedule for deletion in 1.26
- Remove checks on feature gate
- Graduate E2E test to Conformance
Change-Id: I6814819d318edaed5c86dae4055f4b050a4d39fd
at present the spec.csi.secretRef name has to be DNS1035 label
format and it should fail if we use DNSSubdomain secretRef in
the secretReference field of CSI spec. The newly added test cases
validate this behaviour in validation tests for controllerPublish,
nodePublish and nodeStage secretRef formats.
Additionally csiExpansionEnabled struct field also removed from
the validation function.
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
This commit adds the validation tests for CSIVolumeSource explictly.
Also validate driver,nodePublishSecretRef..etc
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
Extra test conditions are added in CSIPersistentVolumeSource validation
for controllerPublishSecretRef and nodePublishSecretRef name and namespace to check
whether name field or namespace field is missing from the secretRef while
validating CSI PersistentVolumeSource
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
Signed-off-by: wangyysde <net_use@bzhy.com>
Generation swagger.json.
Use v2 path for hpa_cpu_field.
run update-codegen.sh
Signed-off-by: wangyysde <net_use@bzhy.com>
* De-share the Handler struct in core API
An upcoming PR adds a handler that only applies on one of these paths.
Having fields that don't work seems bad.
This never should have been shared. Lifecycle hooks are like a "write"
while probes are more like a "read". HTTPGet and TCPSocket don't really
make sense as lifecycle hooks (but I can't take that back). When we add
gRPC, it is EXPLICITLY a health check (defined by gRPC) not an arbitrary
RPC - so a probe makes sense but a hook does not.
In the future I can also see adding lifecycle hooks that don't make
sense as probes. E.g. 'sleep' is a common lifecycle request. The only
option is `exec`, which requires having a sleep binary in your image.
* Run update scripts
Since the only member of that struct is gone, the struct itself can also be
removed. If for whatever reason the struct is needed again, then this commit
can be reverted to bring it back.
Listing these explicitly makes it easier to determine whether a new
Container field has been evaluated for use with ephemeral containers.
This does not change the behavior of ephemeral containers.
to keep a count of the pods that have the ready condition.
Also:
- Add feature gate JobReadyPods.
- Add Ready to describe.
Change-Id: Ib934730a430a8e2a2f485671e345fe2330006939
Enable feature by default.
Update integration tests for other features to assume that finalizers are present.
Change-Id: Ie969344f572627dba882c0e862e5700dadaf3026
The feature gate gets locked to "true", with the goal to remove it in two
releases.
All code now can assume that the feature is enabled. Tests for "feature
disabled" are no longer needed and get removed.
Some code wasn't using the new helper functions yet. That gets changed while
touching those lines.
This adds a test case to cover the scenario where the fields of an
ephemeral container conflict with other fields in the pod and must be
detected by full PodSpec validation.
Previously this only validated the ephemeral containers, but it's safer
to validate the entire PodSpec in case other parts of validation add
logic that checks ephemeral containers.
* Updates ImpersonationConfig in rest/config.go to include UID
attribute, and pass it through when copying the config
* Updates ImpersonationConfig in transport/config.go to include UID
attribute
* In transport/round_tripper.go, Set the "Impersonate-Uid" header in
requests based on the UID value in the config
* Update auth_test.go integration test to specify a UID through the new
rest.ImpersonationConfig field rather than manually setting the
Impersonate-Uid header
Signed-off-by: Margo Crawford <margaretc@vmware.com>
Remove the VolumeSubpath feature gate.
Feature gate convention has been updated since this was introduced to
indicate that they "are intended to be deprecated and removed after a
feature becomes GA or is dropped.".
This commit started as removing FIXME comments, but in doing so I
realized that the IP allocation process was using unvalidated user
input. Before de-layering, validation was called twice - once before
init and once after, which the init code depended on.
Fortunately (or not?) we had duplicative checks that caught errors but
with less friendly messages.
This commit calls validation before initializing the rest of the
IP-related fields.
This also re-organizes that code a bit, cleans up error messages and
comments, and adds a test SPECIFICALLY for the errors in those cases.
This was causing tests to pass which ought not be passing. This is not
an API change because we default the value of it when needed. So we
would never see this in the wild, but it makes the tests sloppy.
This is the last layered method. All allocator logic is moved to the
beginUpdate() path. Removing the now-useless layer will happen in a
subsequent commit.
When originally introduced, the field was made immutable to be
consistent with the other fields. But in practice allowing it to be
toggled makes more sense, in particular when considering the rollout
of a CSI driver (let it run without using the published
CSIStorageCapacity object, then flip the field, or upgrading from a
driver without support to one which supports it).
The only consumer of this field, the kube-scheduler, can handle
mutation without problems because it always consults the informer
cache to get the current value.
For tracking Job Pods that have finished but are not yet counted as failed or succeeded
And feature gate JobTrackingWithFinalizers
Change-Id: I3e080f3ec090922640384b692e88eaf9a544d3b5
Modify the behavior of the AnyVolumeDataSource alpha feature gate to enable
a new field, DataSourceRef, rather than modifying the behavior of the
existing DataSource field. This allows addition Volume Populators in a way
that doesn't risk breaking backwards compatibility, although it will
result in eventually deprecating the DataSource field.
* pkg/features: promote the ServiceInternalTrafficPolicy field to Beta and on by default
Signed-off-by: Andrew Sy Kim <kim.andrewsy@gmail.com>
* pkg/api/service/testing: update Service test fixture functions to set internalTrafficPolicy=Cluster by default
Signed-off-by: Andrew Sy Kim <kim.andrewsy@gmail.com>
* pkg/apis/core/validation: add more Service validation tests for internalTrafficPolicy
Signed-off-by: Andrew Sy Kim <kim.andrewsy@gmail.com>
* pkg/registry/core/service/storage: fix failing Service REST storage tests to use internalTrafficPolicy: Cluster
Signed-off-by: Andrew Sy Kim <kim.andrewsy@gmail.com>
* pkg/registry/core/service/storage: add two test cases for Service REST TestServiceRegistryInternalTrafficPolicyClusterThenLocal and TestServiceRegistryInternalTrafficPolicyLocalThenCluster
Signed-off-by: Andrew Sy Kim <kim.andrewsy@gmail.com>
* pkg/registry/core/service: update strategy unit tests to expect default
internalTrafficPolicy=Cluster
Signed-off-by: Andrew Sy Kim <kim.andrewsy@gmail.com>
* pkg/proxy/ipvs: fix unit test Test_EndpointSliceReadyAndTerminatingLocal to use internalTrafficPolicy=Cluster
Signed-off-by: Andrew Sy Kim <kim.andrewsy@gmail.com>
* pkg/apis/core: update fuzzers to set Service internalTrafficPolicy field
Signed-off-by: Andrew Sy Kim <kim.andrewsy@gmail.com>
* pkg/api/service/testing: refactor Service test fixtures to use Tweak funcs
Signed-off-by: Andrew Sy Kim <kim.andrewsy@gmail.com>
1. create LB type svc with nodeport allocation set to false
1. create LB type svc with nodeport allocation unset
3. update LB type svc's nodeport allocation field
Signed-off-by: Hanlin Shi <shihanlin9@gmail.com>
1. add AllocateLoadBalancerNodePorts fields in specs for validation test cases
2. update fuzzer
3. in resource quota e2e, allocate node port for loadbalancer type service and
exceed the node port quota
Signed-off-by: Hanlin Shi <shihanlin9@gmail.com>
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>
This will only work if the "ReadWriteOncePod" feature gate is enabled.
Additionally, this access mode will only work when used by itself. This
is because when ReadWriteOncePod is used on a PV or PVC, it renders all
other access modes useless since it is most restrictive.
Fix the godoc for RollingUpdateDaemonSet to state that
spec.updateStrategy.rollingUpdate.maxUnavailable is rounded up.
A recent commit changed the godoc to say that the value of this field
was rounded down, but the actual implementation rounds up and always has
rounded up. (This is in contrast to Deployments, where
spec.strategy.rollingUpdate.maxUnavailable is rounded down.)
Follow-up to commit 5aa53f885c.
* api/openapi-spec/swagger.json:
* staging/src/k8s.io/api/apps/v1/generated.proto:
* pkg/apis/apps/types.go:
* staging/src/k8s.io/api/apps/v1/types.go:
* staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go:
* staging/src/k8s.io/api/apps/v1beta2/generated.proto:
* staging/src/k8s.io/api/apps/v1beta2/types.go:
* staging/src/k8s.io/api/apps/v1beta2/types_swagger_doc_generated.go:
* staging/src/k8s.io/api/extensions/v1beta1/generated.proto:
* staging/src/k8s.io/api/extensions/v1beta1/types.go:
* staging/src/k8s.io/api/extensions/v1beta1/types_swagger_doc_generated.go:
* staging/src/k8s.io/cli-runtime/artifacts/openapi/swagger.json:
* staging/src/k8s.io/kubectl/testdata/openapi/swagger.json:
Change "rounding down" to "rounding up".
When the StatefulSetMinReadySeconds feature gate is disabled,
the registry and validation must properly handle dropping the
minReadySeconds and AvailableReplicas fields
The minReadySeconds field on StatefulSet specifies the minimum
number of seconds for which a newly created Pod should be
ready without any of its containers crashing, for it to
be considered available. The AvailableReplicas field
in the status reflects the replicas that are available
