Route53 based example #3367
Route53 based example #3367
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
|
Hi @tigerlinux. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
k8s-ci-robot
added
needs-ok-to-test
|
/ok-to-test |
k8s-ci-robot
removed
the
needs-ok-to-test
|
|
||
| ## WHAT WE WANT TO ACOMPLISH HERE ?. | ||
|
|
||
| The exercise described on this document will focus on the following goals: |
| @@ -0,0 +1,870 @@ | |||
| # USING KOPS WITH A ROUTE53 BASED SUBDOMAIN AND SCALING UP THE CLUSTER | |||
|
|
|||
| ## WHAT WE WANT TO ACOMPLISH HERE ?. | |||
|
|
||
| Ensure that the following points are covered and working in your environment: | ||
|
|
||
| - "jq" utility installed (this is available on most linux distributions). If you are running on Centos, you'll need to add "epel" repository with `yum -y install epel-release` then install jq with `yum -y install jq`. |
There was a problem hiding this comment.
available on most operating systems? Or include OS X
| Ensure that the following points are covered and working in your environment: | ||
|
|
||
| - "jq" utility installed (this is available on most linux distributions). If you are running on Centos, you'll need to add "epel" repository with `yum -y install epel-release` then install jq with `yum -y install jq`. | ||
| - "dig" utility installed (this is also available on most linux distributions). We'll need "dig" in order to tests our DNS subdomain. On "centos/rhel" distros, this utility is part of the "bind-utils" package. |
There was a problem hiding this comment.
An English nit pick. You can drop most of the parenthesis. No need to change.
|
|
||
| - "jq" utility installed (this is available on most linux distributions). If you are running on Centos, you'll need to add "epel" repository with `yum -y install epel-release` then install jq with `yum -y install jq`. | ||
| - "dig" utility installed (this is also available on most linux distributions). We'll need "dig" in order to tests our DNS subdomain. On "centos/rhel" distros, this utility is part of the "bind-utils" package. | ||
| - AWS cli fully configured (aws account already with proper permissions/roles needed for kops). Depending on your distro, you can setup directly from packages, or if you want the most updated version, use "pip" and install awscli by issuing a "pip install awscli" command. Your choice !. |
| --zones=us-east-1a,us-east-1b,us-east-1c \ | ||
| --node-count=2 \ | ||
| --topology private \ | ||
| --networking kopeio-vxlan \ |
There was a problem hiding this comment.
Make a note about other cni providers, and that you need CNI with this setup.
There was a problem hiding this comment.
You did actually, mention that you have to have cni, as kubenet does not work
| - The "--topology private" argument will ensure that all our instances will have private IP's and no public IP's from amazon. | ||
| - We are including the arguments "--node-size" and "master-size" to specify the "instance types" for both our masters and worker nodes. | ||
| - And finally, the "--networking kopeio-vxlan" argument. With the private networking model, we need to tell kops which networking subsystem to use. More information about kops supported networking models can be obtained from the [KOPS Kubernetes Networking Documentation](https://github.com/kubernetes/kops/blob/master/docs/networking.md). For this exercise we'll use "kopeio-vxlan" (or "kopeio" for short). | ||
|
|
There was a problem hiding this comment.
Can you do the short link?
| - We are including the arguments "--node-size" and "master-size" to specify the "instance types" for both our masters and worker nodes. | ||
| - And finally, the "--networking kopeio-vxlan" argument. With the private networking model, we need to tell kops which networking subsystem to use. More information about kops supported networking models can be obtained from the [KOPS Kubernetes Networking Documentation](https://github.com/kubernetes/kops/blob/master/docs/networking.md). For this exercise we'll use "kopeio-vxlan" (or "kopeio" for short). | ||
|
|
||
| **NOTE**: You can add the "--bastion" argument here if you are not using "gossip dns" and create the bastion from start, but if you are using "gossip-dns" this will make this cluster to fail (this is a bug we are correcting now). For the moment don't use "--bastion" when using gossip DNS. We'll show you how to get around this by first creating the private cluster, then creation the bastion instance group once the cluster is running. |
There was a problem hiding this comment.
This is a bug, can you reference the issue?
There was a problem hiding this comment.
Ok. Let me find the issue, but if you have the number and link... better :D
| Our bastion instance group is there. Also, kops created an ELB for our "bastions" instance group that we can check with the following command: | ||
|
|
||
| ```bash | ||
| aws elb --output=table describe-load-balancers|grep DNSName.\*bastion|awk '{print $4}' |
There was a problem hiding this comment.
There should be a friendly DNS name setup for the bastion elb
There was a problem hiding this comment.
Never mind you did gossip
There was a problem hiding this comment.
jajjajajaa roger that !
|
|
||
| ## MAKING THE BASTION LAYER "HIGLY AVAILABLE". | ||
|
|
||
| If for any reason "godzilla" decides to destroy the amazon AZ that contains our bastion, we'll basically be unable to enter to our instances. Let's add some H.A. to our bastion layer and force amazon to deploy additional bastion instances on other availability zones. |
There was a problem hiding this comment.
Godzilla may be copywrited, we may want to use a monster?
There was a problem hiding this comment.
jajaja.. yup you're right he may be copyrighted. I'll take all recommendations and requested changes into account. Putting a common "preflight" section and using chapters is a good idea. I'm going to work on the modifications during the next days, then send a new PR with all changes.
There was a problem hiding this comment.
Changed to "legendary monster from the comics"... hehehe...
|
Marking this wip as you mentioned you want to combine and tweak both of your awesome PRs |
tigerlinux
force-pushed
the
route53_based_example
branch
from
dea5ce1 to
82a7fb3
Compare
|
@tigerlinux PR needs rebase |
k8s-github-robot
added
the
needs-rebase
tigerlinux
force-pushed
the
route53_based_example
branch
from
82a7fb3 to
5d228ae
Compare
k8s-github-robot
removed
the
needs-rebase
|
If you want to merge these in we can iterate. Thoughts? Get them merged and more people can help |
|
Hi there, Question: Do I need to make additional changes to my last PR?. I did the changes requested by Chris and other improvements there but I see the PR is still not passed the tests!. Please let me know what else do I need to change to make it work. |
|
Can you rebase please. Should pass then |
|
Ok sure. Let me do a rebase today then :D |
tigerlinux
force-pushed
the
route53_based_example
branch
from
5d228ae to
cf66ee4
Compare
|
Ok. PR rebased and sent!. |
|
Let's get this merged - I'll go through it in detail then and send a few suggestions, but looks like they will be silly nit-pick stuff :-) Thanks - this is awesome! /lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: justinsb The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
k8s-github-robot
added
the
approved
|
Automatic merge from submit-queue. |
Added in the docs/examples section a new practical example/lab with the use of a route53-based subdomain. All technical details and commands (both for kops and aws) fully included.