add io2 case and correct IOPS minimum value check
add gp3 case
add io2 and gp3 parameter ratio validation logic
add volumeThroughput parameter for disks that support it
add volumeThroughput components throughout ebs structs
add volumeThroughput to versioned api
updated api machinery and crds
apimachinery update
There is no real reason to do this. In some cases this may even prevent
clusters from starting where there is no explicit volume type defined in
cinder.
This is causing problems with the Kubernetes 1.19 code-generator.
A nil entry in these slices wouldn't be valid anyways, so this should have no impact.
We don't call klog.InitFlags yet, because that will cause a flag
redefinition error until we get everyone to stop using glog. That
will happen when we update to k8s 1.13.
In AWS the ratio between volume IOPS and volume size must be at most 50,
otherwise volume will fail creating. See
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html,
specifically "_The maximum ratio of provisioned IOPS to requested volume size
(in GiB) is 50:1. For example, a 100 GiB volume can be provisioned with up to
5,000 IOPS._"
This commit adds the option of failing fast when creating a new cluster if the
ratio is higher than 50. Previously kops would send the API request to AWS, fail
and repeat until the timeout was reached.
The current implementation does not put any transport security on the etcd cluster. The PR provides and optional flag to enable TLS the etcd cluster
- cleaned up and fixed any formatting issues on the journey
- added two new certificates (server/client) for etcd peers and a client certificate for kubeapi and others perhaps (perhaps calico?)
- disabled the protokube service for nodes completely is not required; note this was first raised in https://github.com/kubernetes/kops/pull/3091, but figured it would be easier to place in here given the relation
- updated protokube codebase to reflect the changes, removing the master option as its no longer required
- added additional integretion tests for the protokube manifests;
- note, still need to add documentation, but opening the PR to get feedback
- one outstanding issue is the migration from http -> https for preexisting clusters, i'm gonna hit the coreos board to ask for the best options
Accept vSphere's server, datacenter, cluster setting by flags
"vsphere-server", "vsphere-datacenter", and "vsphere-resource-pool".
Username and password can be set by environment variables:
"VSPHERE_USERNAME" and "VSPHERE_PASSWORD".
We move everything to the models. We feature-flag it, because we
probably want to change the names etc, and we aren't going to be able to
offer smooth upgrades until that is done.
* Zones are now subnets
* Utility subnet is no longer part of Zone
* Bastion InstanceGroup type added instead
* Etcd clusters defined in terms of InstanceGroups, not zones
* AdminAccess split into SSHAccess & APIAccess
* Dropped unused Multizone flag
Ciprian Hacman
Kubernetes Prow Robot
msidwell
Kenji Kaneda
Ole Markus With
Peter Rifel
John Gardiner Myers
Xiaoyu Zhong
Srikanth
mikesplain
Justin SB
Jesse Haka
Vlad Ionescu
LilyFaFa
Sergey Lanzman
Justin Santa Barbara
zengchen1024
andrewsykim
Rohith
Pierre-Alexandre St-Jean
Miao Luo