Automatic merge from submit-queue
Add documentation on handling node resources
At a minimum, this is meant to give more context on why the feature in https://github.com/kubernetes/kops/pull/2982 was added and attempts to give some recommendations of what to consider when evaluating node system resources.
I hope this spurs some discussion and that the recommendations I make maybe be assessed further. For example ... in one of the links I referenced, we're advised to set `system-reserved` **only if we know what we are doing** (which I can't say I do 💯% ... 🤷♂️) and we're even warned to only set it if you really need to.
- switched to using an array of roles rather than boolean flags for node selection
- fixed up the README to reflect the changes
- added the docker.service as a Requires to all docker exec hooks
- extending the hooks to permit adding hooks per instancegroup as well
- @note, instanceGroup are permitted to override the cluster wide one for ease of testing
- updated the documentation to reflect the changes
- on the journey tried to fix an go idioms such as import ordering, comments for global export etc
- @question: v1alpha1 doesn't appear to have Subnet fields, are these different version being used anywhere?
The present implementation of hooks only perform for docker exec, which isn't that flexible. This PR permits the user to greater customize systemd units on the instances
- cleaned up the manifest code, added tests and permit setting a section raw
- added the ability to filter hooks via master and node roles
- updated the documentation to reflect the changes
- cleaned up some of the vetting issues
The current implementation does not permit the user to order the hooks. This PR adds optional Requires, Before and Documentation to the HookSpec which is added the systemd unit if specified.
Automatic merge from submit-queue
Kubelet API Certificate
A while back options to permit secure kube-apiserver to kubelet api was [PR2381](https://github.com/kubernetes/kops/pull/2831) using the server.cert and server.key as testing grounds. This PR formalizes the options and generates a client certificate on their behalf (note, the server{.cert,key} can no longer be used post 1.7 as the certificate usage is checked i.e. it's not using a client cert). The users now only need to add anonymousAuth: false to enable secure api to kubelet. I'd like to make this default to all new builds i'm not sure where to place it.
- updated the security.md to reflect the changes
- issue a new client kubelet-api certificate used to secure authorize comms between api and kubelet
- fixed any formatting issues i came across on the journey
Automatic merge from submit-queue
Clarify docs: rename spec/specification into desired configuration
The cluster state in S3 has (among others) two files: `cluster.spec` and `config`.
When the documentation mentioned "create or update cluster spec" for example, it was confusing what was actually updated. It's not the cluster.spec file.
As I understand, `cluster.spec` should only be created/updated after `kops update --yes` is run.
I changed the docs for `kops get`, `kops create`, `kops replace`, `kops edit`.
I did NOT change those files: `kops_rolling-update.md`, `kops_rolling-update_cluster.md` as I think those actually use `cluster.spec`.
In the S3 bucket, the file cluster.spec is not actually the spec, but the
actual configuration. The file config is the spec. To avoid confusion,
this commit changes spec/specification into 'desired configuration' in
the documentation, to avoid associating cluster.spec with a cluster
'specification' that the users should use.
- fixed the various issues highlighted in https://github.com/kubernetes/kops/pull/3125
- changed the docuementation to make more sense
- changed the logic of the UseSecureKubelet to return early
A while back options to permit secure kube-apiserver to kubelet api was https://github.com/kubernetes/kops/pull/2831 using the server.cert and server.key as testing grouns. This PR formalizes the options and generates a client certificate on their behalf (note, the server{.cert,key} can no longer be used post 1.7 as the certificate usage is checked i.e. it's not using a client cert). The users now only need to add anonymousAuth: false to enable secure api to kubelet. I'd like to make this default to all new builds i'm not sure where to place it.
- updated the security.md to reflect the changes
- issue a new client kubelet-api certificate used to secure authorize comms between api and kubelet
- fixed any formatting issues i came across on the journey
Automatic merge from submit-queue
Add `kops create secret dockerconfig` feature
This adds a well-known secret name `dockerconfig` which will automatically
be used if present to create `/root/.docker/config.json` on all nodes. This will
allow private registries to be used for kops hooks as well as any k8s images
without the need to define `imagePullSecrets` in every namespace.
closes https://github.com/kubernetes/kops/issues/2505
Automatic merge from submit-queue
docs/topology - Fix the rolling-update command
This patch updates the `kops rolling-update` command which should be
run after making changes to the API server topology.
Fixes#3093
Signed-off-by: M S Vishwanath Bhat <msvbhat@gmail.com>
Automatic merge from submit-queue
remove source/destination check requirement for kube-router from docs
Kube-router automatically disables source/destination checks for the AWS
EC2 instances now user need not perform explicitly.
Fixed as part of https://github.com/cloudnativelabs/kube-router/issues/35
Automatic merge from submit-queue
AWS: root volume provisioned IOPS support
It is possible to set `rootVolumeType: gp2` so an instance group will use `gp2` as disk type (https://github.com/kubernetes/kops/blob/master/docs/instance_groups.md)
If the option is set to `rootVolumeType: io1` then the below error is thrown when building the cluster:
`W0731 13:44:44.298875 8784 executor.go:109] error running task "LaunchConfiguration/master-eu-west-1a.masters.cluster.name" (9m48s remaining to succeed): error creating AutoscalingLaunchConfiguration: ValidationError: Iops is required for a provisioned IOPS volume.
status code: 400, request id: 072e23b2-75ee-11e7-968a-191d6f6e9343`
This PR tries to address this so if anyone needs, it can use `io1` as disk type for the root volume.
In order to define the number of Iops set `rootVolumeIops: <number>` (minimum is 100)
If `rootVolumeType: io1` is set and `rootVolumeIops` is not defined, then `rootVolumeIops` defaults to 100.
I am not quite familiar with the Kops codebase and this is my first encounter with Go, so some changes might not be suitable (I also do not have a software developer background so bear with me :) ). Please review and add feed-back.
I've included a small change to the Makefile as I compiled Kops on a Mac and didn't had $GOPATH set after installing Go. I thought that pulling this via `go env` would be more flexible, but I am not 100% sure as I don't do much development in this area and not sure about possible use cases.
This patch updates the `kops rolling-update` command which should be
run after making changes to the API server topology.
Signed-off-by: M S Vishwanath Bhat <msvbhat@gmail.com>
lsowen
Kubernetes Submit Queue
Orr Chen
King'ori Maina
Rohith
Quentin Nerden
Nathan Smith
asifdxtreme
Derek VerLee
Sathiya Shunmugasundaram
Grischa Ekart
Blake
Devipriya Sarkar
Murali Reddy
Markus Padourek
Ionut Craciunescu
Paul Capestany
M S Vishwanath Bhat
AlexB138
Justin Santa Barbara
Jean-Pierre Huynh
craigmonson
Alexander Brandstedt