cluster/gce/coreos: Update configs to enable coreos cluster on gce #17243
Conversation
|
Labelling this PR as size/XXL |
k8s-github-robot
added
the
size/XXL
|
Also as mentioned in #16960 (comment) |
|
GCE e2e build/test failed for commit 449b271f89967e7ee5f0439180b42e8ea27b9fa2. |
|
GCE e2e build/test failed for commit e7e186fa0eebe0ea4c61e0964574811f15658d6b. |
|
@mikedanese no need to review this, but thought you might be interested. |
|
A little background for this: I asked @yifan-gu to extend our gce / coreos support: 1) including master node, 2) introduce docker, not only rkt. By doing this, we can have
|
|
Basically this approach is hybrid of salt/script/cloudconfig.
The salt is not installed or run on coreos. So instead of using salt to evaluate the pod spec templates, I used bash Open to suggestions :) |
k8s-github-robot
added
the
needs-rebase
|
This LGTM |
cluster/gce/coreos/master.yaml
Outdated
There was a problem hiding this comment.
Based on the kubernetes-install-rkt unit, it seems like the rkt binary would end up in /opt/rkt-v${RKT_VERSION}/rkt
|
One question: the api-server.yaml template has less 'VolumeMounts' and 'volumes' compared with the original kube-apiserver.manifest. Does this matter? |
The problem is on coreos, /usr is readonly, and since Wonder if we can write some script to check the templates under each distro first, if that doesn't exit, then use the one under the gce dir? |
|
Yes, I know it is because many dirs in coreos are read only. My question was: does this hurt functionality if we remove some mount volumes and volumes. I briefly read through the files you put in cluster/gce/core/template. This is pretty much to solve the question I asked you offline last week. Since the yaml and manifest files in saltbase have salt configuration mixed there, coreos and ubuntu trusty cannot directly use them. I made some experimental script to parse them and set values, but that way is very error-prone. So, I think your way of making separate copies only container env variables is a good solution for both coreos and trusty. That is why I asked if you could move them to cluster/gce/ to be shared by coreos and trusty. |
k8s-github-robot
removed
the
needs-rebase
|
GCE e2e build/test failed for commit 1baacec2a9902de9b2cc95f565a5b024d793a4a6. |
|
GCE e2e build/test failed for commit 5ced22fca5eaaf411d77aaf44ed7c7e93a98ad96. |
|
@k8s-bot test this please |
|
GCE e2e test build/test passed for commit 5ced22fca5eaaf411d77aaf44ed7c7e93a98ad96. |
Also added create-master-instance() and create-node-instance-template()
|
GCE e2e test build/test passed for commit 723402c. |
brendandburns
added
the
lgtm
|
@k8s-bot test this Tests are more than 48 hours old. Re-running tests. |
|
GCE e2e build/test failed for commit 723402c. |
|
@k8s-bot test this please |
|
GCE e2e test build/test passed for commit 723402c. |
|
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
|
GCE e2e test build/test passed for commit 723402c. |
|
@k8s-bot unit test this please |
|
@k8s-bot test this please |
|
GCE e2e test build/test passed for commit 723402c. |
|
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
|
GCE e2e test build/test passed for commit 723402c. |
|
Automatic merge from submit-queue |
Auto commit by PR queue bot
11 participants
This depends on #17240 and #17241
Basically I maintained a set of pod templates for master components and addons.
When the node is up, it will pull the templates and evaluate them according to the kube-env. (Sort like what salt will do, but here we just use shell).
However it still uses some scripts in the salt: