If the dual-stack flag is enabled and the cluster is single stack IPv6,
the allocator logic for service clusterIP does not properly handle rejecting
a request for an IPv4 family. Return a 422 Invalid on the ipFamily field
when the dual stack flag is on (as it would when it hits beta) and the
cluster is configured for single-stack IPv6.
The family is now defaulted or cleared in BeforeCreate/BeforeUpdate,
and is either inherited from the previous object (if nil or unchanged),
or set to the default strategy's family as necessary. The existing
family defaulting when cluster ip is provided remains in the api
section. We add additonal family defaulting at the time we allocate
the IP to ensure that IPFamily is a consequence of the ClusterIP
and prevent accidental reversion. This defaulting also ensures that
old clients that submit a nil IPFamily for non ClusterIP services
receive a default.
To properly handle validation, make the strategy and the validation code
path condition on which configuration options are passed to service
storage. Move validation and preparation logic inside the strategy where
it belongs. Service validation is now dependent on the configuration of
the server, and as such ValidateConditionService needs to know what the
allowed families are.
This implementation allows Pod to request multiple hugepage resources
of different size and mount hugepage volumes using storage medium
HugePage-<size>, e.g.
spec:
containers:
resources:
requests:
hugepages-2Mi: 2Mi
hugepages-1Gi: 2Gi
volumeMounts:
- mountPath: /hugepages-2Mi
name: hugepage-2mi
- mountPath: /hugepages-1Gi
name: hugepage-1gi
...
volumes:
- name: hugepage-2mi
emptyDir:
medium: HugePages-2Mi
- name: hugepage-1gi
emptyDir:
medium: HugePages-1Gi
NOTE: This is an alpha feature.
Feature gate HugePageStorageMediumSize must be enabled for it to work.
Remove the validation for pre-allocated hugepages on node level.
Validation is currently the only thing making it impossible to use
pre-allocated huge pages in more than one size.
We have now quite a few reports from real users that this feature is
welcome.
add host file write for podIPs
update tests
remove import alias
update type check
update type check
remove import alias
update open api spec
add tests
update test
add tests
address review comments
update imports
remove todo and import alias
* Fix lint errors related to receiver name
Ref #68026
* Fix lint errors related to comments
Ref #68026
* Fix package name in comments
Ref #68026
* Rename Cpu to CPU
Ref #68026
* Fix lint errors related to naming convention
Ref #68026
* Remove deprecated field
DoNotUse_ExternalID has been deprecated and is not in use anymore.
It has been removed to fix lint errors related to underscores in field
names.
Ref #68026, #61966
* Include pkg/apis/core in golint check
Ref #68026
* Rename var to fix lint errors
Ref #68026
* Revert "Remove deprecated field"
This reverts commit 75e9bfc168077fcb9346e334b59d60a2c997735b.
Ref #82919
* Remove math from godoc
Ref #82919, #68026
* Remove underscore from var name
Ref #68026
* Rename var in staging core api type
Ref #68026
Currently, the character limit for the usernames set in the RunAsUserName is 20,
which is too low, considering that "ContainerAdministrator" is a valid username and
it is longer than 20 characters. A user should be able to run containers as
Administrator, if needed.
According to [1], Logon names can be up to 104 characters. The previous limit
only applies to local user accounts for the local system.
[1] https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/bb726984(v=technet.10)
Adds the field RunAsUserName in the WindowsSecurityContextOptions type,
which is used in PodSecurityContext and SecurityContext.
This field needs to allow for a valid set of usernames allowed for
Windows containers. It must have the format "U
This commit also validates the runAsUserName field, making sure that it valid,
having the format DOMAIN\USER (case insensitive), where DOMAIN\ is optional and
has to be a valid NetBios or DNS domain name.
For more information about the restrictions on the DOMAIN and USER parts, look here: [1] [2]
Adds the WindowsRunAsUserName alpha feature gate. By default, it is disabled.
If the feature gate is not enabled, the WindowsOptions.RunAsUserName field
will be dropped from both the PodSecurityContext and container
SecurityContext.
Co-Authored-By: Claudiu Belu <cbelu@cloudbasesolutions.com>
[1] https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and
[2] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1
