openshift/installer
1
0
Fork 0
mirror of https://github.com/openshift/installer.git synced 2026-02-05 06:46:36 +01:00
Code Issues Releases Activity
Files
f67c283cb0a21cda540fe609d21f8c110b632a68
installer/docs/user/aws/install.md

85 lines
3.6 KiB
Markdown
Raw Normal View History

Adding user doc/guide for AWS account and installation
2019-01-09 12:13:17 -05:00
# Cluster Installation
Adding initial user doc/guide & materials for UPI AWS installation Moved the encrypted-AMI section from "Create Cluster" to "Running Cluster", because it has more value there folks inspecting their account and what has happened after the fact. Since we call out the running instances (by count with a picture) they may wonder "where did this unique AMI come from it is running"? It goes along with some of the other explanations we chase with as well. The Create Cluster section just has the whole IPI output, but no explanation of all wizardry under the covers, calling this particular wrinkle out there seemed a bit awkward to me.
2019-03-12 20:56:09 -04:00
At this point, you are ready to perform the OpenShift installation. You have two choices for installing your cluster on
AWS, Installer-Provided Infrastructure (IPI) or User-Provided Infrastructure (UPI). See below for an example of an
IPI install.
To see a guided example of a UPI install, please see [Install: User-Provided Infrastructure](install_upi.md)
Adding user doc/guide for AWS account and installation
2019-01-09 12:13:17 -05:00
Adding initial user doc/guide & materials for UPI AWS installation Moved the encrypted-AMI section from "Create Cluster" to "Running Cluster", because it has more value there folks inspecting their account and what has happened after the fact. Since we call out the running instances (by count with a picture) they may wonder "where did this unique AMI come from it is running"? It goes along with some of the other explanations we chase with as well. The Create Cluster section just has the whole IPI output, but no explanation of all wizardry under the covers, calling this particular wrinkle out there seemed a bit awkward to me.
2019-03-12 20:56:09 -04:00
## Example: Installer-Provided Infrastructure (IPI)
The steps for performing an IPI-based install are outlined [here][cloud-install]. Following this guide you may begin at
Step 3: Download the Installer.
Adding user doc/guide for AWS account and installation
2019-01-09 12:13:17 -05:00
Bug 2094716: docs: fully air-gapped AWS IPI install Fully air-gapped installation is not possible.
2022-07-04 16:04:38 +02:00
## Fully air-gapped installation
It is not possible to install Openshift on AWS in a fully air-gapped design because the installation process requires Internet access to use the route 53 API, as documented in the [AWS route 53 FAQ][aws-faq]:
```
Do I need connectivity to the outside Internet in order to use Private DNS?
You can resolve internal DNS names from resources within your VPC that do not have Internet connectivity. However, to update the configuration for your Private DNS hosted zone, you need Internet connectivity to access the Route 53 API endpoint, which is outside of VPC.
```
Adding user doc/guide for AWS account and installation
2019-01-09 12:13:17 -05:00
### Create Configuration
```console
docs/user/aws/install: openshift-install-linux-amd64 -> openshift-install The OS/arch suffix was an artifact of our GitHub release approach (e.g. [1]). With the new mirror approach, the flow is going to be more like: $ wget https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/openshift-install-linux-4.1.0-rc.5.tar.gz $ tar xf openshift-install-linux-4.1.0-rc.5.tar.gz $ ./openshift-install ... But folks could install into their PATH, and our current docs prefer the in-the-PATH form, so that's what I've gone with here. [1]: https://github.com/openshift/installer/releases/tag/v0.16.1
2019-05-22 16:56:31 -07:00
$ openshift-install create install-config
Adding user doc/guide for AWS account and installation
2019-01-09 12:13:17 -05:00
? SSH Public Key /home/user_id/.ssh/id_rsa.pub
? Platform aws
? Region us-east-1
cmd/openshift-install/upi: Add a user-provided-infrastructure subcommand To support the workflow described in upiLong. I've also replaced openshiftcorp.com with example.com to comply with [1]. That way readers don't need to worry about whether openshiftcorp.com exists and, if so, who owns it. I've updated the docs/user/aws/install.md examples to follow our current (with this PR) output: $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_installer/1393/pull-ci-openshift-installer-master-e2e-aws/4457/artifacts/e2e-aws/installer/.openshift_install.log | grep level=info | head -n13 time="2019-03-12T16:34:33Z" level=info msg="Consuming \"Install Config\" from target directory" time="2019-03-12T16:34:33Z" level=info msg="Creating cluster..." time="2019-03-12T16:51:21Z" level=info msg="Waiting up to 30m0s for the Kubernetes API at https://api.ci-op-j33s61i6-1d3f3.origin-ci-int-aws.dev.rhcloud.com:6443..." time="2019-03-12T16:55:29Z" level=info msg="API v1.12.4+341c822 up" time="2019-03-12T16:55:29Z" level=info msg="Waiting up to 30m0s for the bootstrap-complete event..." time="2019-03-12T17:04:56Z" level=info msg="Destroying the bootstrap resources..." time="2019-03-12T17:05:36Z" level=info msg="Waiting up to 30m0s for the cluster at https://api.ci-op-j33s61i6-1d3f3.origin-ci-int-aws.dev.rhcloud.com:6443 to initialize..." time="2019-03-12T17:14:56Z" level=info msg="Waiting up to 10m0s for the openshift-console route to be created..." time="2019-03-12T17:14:56Z" level=info msg="Install complete!" time="2019-03-12T17:14:56Z" level=info msg="Run 'export KUBECONFIG=/tmp/artifacts/installer/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI." time="2019-03-12T17:14:56Z" level=info msg="The cluster is ready when 'oc login -u kubeadmin -p 3MJb2-RRTfu-SKyuq-5NcCb' succeeds (wait a few minutes)." time="2019-03-12T17:14:56Z" level=info msg="Access the OpenShift web-console here: https://console-openshift-console.apps.ci-op-j33s61i6-1d3f3.origin-ci-int-aws.dev.rhcloud.com" time="2019-03-12T17:14:56Z" level=info msg="Login to the console with user: kubeadmin, password: 3MJb2-RRTfu-SKyuq-5NcCb" [1]: https://tools.ietf.org/html/rfc6761#section-6.5
2019-03-08 12:49:36 -08:00
? Base Domain example.com
Adding user doc/guide for AWS account and installation
2019-01-09 12:13:17 -05:00
? Cluster Name test
? Pull Secret [? for help]
```
### Create Cluster
```console
docs/user/aws/install: openshift-install-linux-amd64 -> openshift-install The OS/arch suffix was an artifact of our GitHub release approach (e.g. [1]). With the new mirror approach, the flow is going to be more like: $ wget https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/openshift-install-linux-4.1.0-rc.5.tar.gz $ tar xf openshift-install-linux-4.1.0-rc.5.tar.gz $ ./openshift-install ... But folks could install into their PATH, and our current docs prefer the in-the-PATH form, so that's what I've gone with here. [1]: https://github.com/openshift/installer/releases/tag/v0.16.1
2019-05-22 16:56:31 -07:00
$ openshift-install create cluster
cmd/openshift-install/upi: Add a user-provided-infrastructure subcommand To support the workflow described in upiLong. I've also replaced openshiftcorp.com with example.com to comply with [1]. That way readers don't need to worry about whether openshiftcorp.com exists and, if so, who owns it. I've updated the docs/user/aws/install.md examples to follow our current (with this PR) output: $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_installer/1393/pull-ci-openshift-installer-master-e2e-aws/4457/artifacts/e2e-aws/installer/.openshift_install.log | grep level=info | head -n13 time="2019-03-12T16:34:33Z" level=info msg="Consuming \"Install Config\" from target directory" time="2019-03-12T16:34:33Z" level=info msg="Creating cluster..." time="2019-03-12T16:51:21Z" level=info msg="Waiting up to 30m0s for the Kubernetes API at https://api.ci-op-j33s61i6-1d3f3.origin-ci-int-aws.dev.rhcloud.com:6443..." time="2019-03-12T16:55:29Z" level=info msg="API v1.12.4+341c822 up" time="2019-03-12T16:55:29Z" level=info msg="Waiting up to 30m0s for the bootstrap-complete event..." time="2019-03-12T17:04:56Z" level=info msg="Destroying the bootstrap resources..." time="2019-03-12T17:05:36Z" level=info msg="Waiting up to 30m0s for the cluster at https://api.ci-op-j33s61i6-1d3f3.origin-ci-int-aws.dev.rhcloud.com:6443 to initialize..." time="2019-03-12T17:14:56Z" level=info msg="Waiting up to 10m0s for the openshift-console route to be created..." time="2019-03-12T17:14:56Z" level=info msg="Install complete!" time="2019-03-12T17:14:56Z" level=info msg="Run 'export KUBECONFIG=/tmp/artifacts/installer/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI." time="2019-03-12T17:14:56Z" level=info msg="The cluster is ready when 'oc login -u kubeadmin -p 3MJb2-RRTfu-SKyuq-5NcCb' succeeds (wait a few minutes)." time="2019-03-12T17:14:56Z" level=info msg="Access the OpenShift web-console here: https://console-openshift-console.apps.ci-op-j33s61i6-1d3f3.origin-ci-int-aws.dev.rhcloud.com" time="2019-03-12T17:14:56Z" level=info msg="Login to the console with user: kubeadmin, password: 3MJb2-RRTfu-SKyuq-5NcCb" [1]: https://tools.ietf.org/html/rfc6761#section-6.5
2019-03-08 12:49:36 -08:00
INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
Adding user doc/guide for AWS account and installation
2019-01-09 12:13:17 -05:00
INFO API v1.11.0+85a0623 up
INFO Waiting up to 30m0s for the bootstrap-complete event...
INFO Destroying the bootstrap resources...
cmd/openshift-install/upi: Add a user-provided-infrastructure subcommand To support the workflow described in upiLong. I've also replaced openshiftcorp.com with example.com to comply with [1]. That way readers don't need to worry about whether openshiftcorp.com exists and, if so, who owns it. I've updated the docs/user/aws/install.md examples to follow our current (with this PR) output: $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_installer/1393/pull-ci-openshift-installer-master-e2e-aws/4457/artifacts/e2e-aws/installer/.openshift_install.log | grep level=info | head -n13 time="2019-03-12T16:34:33Z" level=info msg="Consuming \"Install Config\" from target directory" time="2019-03-12T16:34:33Z" level=info msg="Creating cluster..." time="2019-03-12T16:51:21Z" level=info msg="Waiting up to 30m0s for the Kubernetes API at https://api.ci-op-j33s61i6-1d3f3.origin-ci-int-aws.dev.rhcloud.com:6443..." time="2019-03-12T16:55:29Z" level=info msg="API v1.12.4+341c822 up" time="2019-03-12T16:55:29Z" level=info msg="Waiting up to 30m0s for the bootstrap-complete event..." time="2019-03-12T17:04:56Z" level=info msg="Destroying the bootstrap resources..." time="2019-03-12T17:05:36Z" level=info msg="Waiting up to 30m0s for the cluster at https://api.ci-op-j33s61i6-1d3f3.origin-ci-int-aws.dev.rhcloud.com:6443 to initialize..." time="2019-03-12T17:14:56Z" level=info msg="Waiting up to 10m0s for the openshift-console route to be created..." time="2019-03-12T17:14:56Z" level=info msg="Install complete!" time="2019-03-12T17:14:56Z" level=info msg="Run 'export KUBECONFIG=/tmp/artifacts/installer/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI." time="2019-03-12T17:14:56Z" level=info msg="The cluster is ready when 'oc login -u kubeadmin -p 3MJb2-RRTfu-SKyuq-5NcCb' succeeds (wait a few minutes)." time="2019-03-12T17:14:56Z" level=info msg="Access the OpenShift web-console here: https://console-openshift-console.apps.ci-op-j33s61i6-1d3f3.origin-ci-int-aws.dev.rhcloud.com" time="2019-03-12T17:14:56Z" level=info msg="Login to the console with user: kubeadmin, password: 3MJb2-RRTfu-SKyuq-5NcCb" [1]: https://tools.ietf.org/html/rfc6761#section-6.5
2019-03-08 12:49:36 -08:00
INTO Waiting up to 30m0s for the cluster at https://api.test.example.com:6443 to initialize...
Adding user doc/guide for AWS account and installation
2019-01-09 12:13:17 -05:00
INFO Waiting up to 10m0s for the openshift-console route to be created...
INFO Install complete!
Print the "export KUBECONFIG=..." command on its own line for easier cut-and-paste
2022-03-17 10:58:50 -04:00
INFO To access the cluster as the system:admin user when using 'oc', run
export KUBECONFIG=/home/user/auth/kubeconfig
cmd/openshift-install/upi: Add a user-provided-infrastructure subcommand To support the workflow described in upiLong. I've also replaced openshiftcorp.com with example.com to comply with [1]. That way readers don't need to worry about whether openshiftcorp.com exists and, if so, who owns it. I've updated the docs/user/aws/install.md examples to follow our current (with this PR) output: $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_installer/1393/pull-ci-openshift-installer-master-e2e-aws/4457/artifacts/e2e-aws/installer/.openshift_install.log | grep level=info | head -n13 time="2019-03-12T16:34:33Z" level=info msg="Consuming \"Install Config\" from target directory" time="2019-03-12T16:34:33Z" level=info msg="Creating cluster..." time="2019-03-12T16:51:21Z" level=info msg="Waiting up to 30m0s for the Kubernetes API at https://api.ci-op-j33s61i6-1d3f3.origin-ci-int-aws.dev.rhcloud.com:6443..." time="2019-03-12T16:55:29Z" level=info msg="API v1.12.4+341c822 up" time="2019-03-12T16:55:29Z" level=info msg="Waiting up to 30m0s for the bootstrap-complete event..." time="2019-03-12T17:04:56Z" level=info msg="Destroying the bootstrap resources..." time="2019-03-12T17:05:36Z" level=info msg="Waiting up to 30m0s for the cluster at https://api.ci-op-j33s61i6-1d3f3.origin-ci-int-aws.dev.rhcloud.com:6443 to initialize..." time="2019-03-12T17:14:56Z" level=info msg="Waiting up to 10m0s for the openshift-console route to be created..." time="2019-03-12T17:14:56Z" level=info msg="Install complete!" time="2019-03-12T17:14:56Z" level=info msg="Run 'export KUBECONFIG=/tmp/artifacts/installer/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI." time="2019-03-12T17:14:56Z" level=info msg="The cluster is ready when 'oc login -u kubeadmin -p 3MJb2-RRTfu-SKyuq-5NcCb' succeeds (wait a few minutes)." time="2019-03-12T17:14:56Z" level=info msg="Access the OpenShift web-console here: https://console-openshift-console.apps.ci-op-j33s61i6-1d3f3.origin-ci-int-aws.dev.rhcloud.com" time="2019-03-12T17:14:56Z" level=info msg="Login to the console with user: kubeadmin, password: 3MJb2-RRTfu-SKyuq-5NcCb" [1]: https://tools.ietf.org/html/rfc6761#section-6.5
2019-03-08 12:49:36 -08:00
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.test.example.com
Modify kubeadmin usage message, admins should not use kubeadmin via CLI The kubeadmin user should only be used to temporarily access the console, and only until an admin configures a proper Identity Provider. There is no reason to login as the kubeadmin user via CLI. If oauth is broken in a cluster, an admin can still access via CLI as system:admin, but will not be able to access via kube:admin.
2019-04-01 14:25:32 -04:00
INFO Login to the console with user: kubeadmin, password: 5char-5char-5char-5char
Adding user doc/guide for AWS account and installation
2019-01-09 12:13:17 -05:00
```
### Running Cluster
In Route53, there will be a new, private hosted zone (for internal lookups):
![Route53 private hosted zone](images/install_private_hosted_zone.png)
In EC2, there will be 6 running instances:
![EC2 instances after install](images/install_nodes.png)
Adding initial user doc/guide & materials for UPI AWS installation Moved the encrypted-AMI section from "Create Cluster" to "Running Cluster", because it has more value there folks inspecting their account and what has happened after the fact. Since we call out the running instances (by count with a picture) they may wonder "where did this unique AMI come from it is running"? It goes along with some of the other explanations we chase with as well. The Create Cluster section just has the whole IPI output, but no explanation of all wizardry under the covers, calling this particular wrinkle out there seemed a bit awkward to me.
2019-03-12 20:56:09 -04:00
The installation creates an encrypted AMI for the bootstrap and control-plane machines.
The encrypted AMI is [copied][encrypted-copy] from the AMI configured in the control-plane machine-API provider spec,
which is RHCOS by default.
The encryption uses the default EBS key for your target account and region
(`aws kms describe-key --key-id alias/aws/ebs`).
The encrypted AMI is deregistered by `destroy cluster`.
Updating architecture diagram and linking IPI diagram
2019-04-17 15:13:28 -04:00
An architecture diagram for the AWS elements created by the full installation is as depicted:
Adding user doc/guide for AWS account and installation
2019-01-09 12:13:17 -05:00
Updating architecture diagram and linking IPI diagram
2019-04-17 15:13:28 -04:00
![Architecture relationship of ELBs and instances](images/install_upi.svg)
Adding user doc/guide for AWS account and installation
2019-01-09 12:13:17 -05:00
The nodes within the VPC utilize the internal DNS and use the Router and Internal API load balancers. External/Internet
access to the cluster use the Router and External API load balancers. Nodes are spread equally across 3 availability
zones.
The OpenShift console is available via the kubeadmin login provided by the installer:
![OpenShift web console](images/install_console.png)
Update URL from cloud.redhat.com to console.redhat.com The console applications currently in cloud.redhat.com have been moved to to a new URL at console.redhat.com. https://cloud.redhat.com/blog/check-out-our-new-look Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
2021-08-06 10:58:13 +02:00
[cloud-install]: https://console.redhat.com/openshift/create
data/aws: Encrypt the AMI used by the bootstrap and master machines This is a quick hack to get encrypted masters. Ideally we'd want to deregister these on bootstrap-teardown, but handling that nicely will be easier after some cleanups from [1]. As it stands, we'll deregister this as part of the general cluster teardown. Because we don't set kms_key_id [2] we get "the default AWS KMS Key" (according to [2]). AWS docs are not particularly clear about whether users can configure the default key for their account/region to override that default, although it is clear that it defaults to an AWS-managed CMK [3] and that the alias for AMI encryption is alias/aws/ebs [4]. If there is no way to override alias/aws/ebs, we'll probably eventially need to expose kms_key_id to users. [1]: https://github.com/openshift/installer/pull/1148 [2]: https://www.terraform.io/docs/providers/aws/r/ami_copy.html#kms_key_id [3]: https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk [4]: https://aws.amazon.com/blogs/security/how-to-create-a-custom-ami-with-encrypted-amazon-ebs-snapshots-and-share-it-with-other-accounts-and-regions/
2019-02-22 09:18:00 -08:00
[encrypted-copy]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIEncryption.html#create-ami-encrypted-root-snapshot
Bug 2094716: docs: fully air-gapped AWS IPI install Fully air-gapped installation is not possible.
2022-07-04 16:04:38 +02:00
[aws-faq]: https://aws.amazon.com/route53/faqs/
Copy Permalink