├── .gitignore ├── README.md ├── assets ├── cb-example-auth.yaml ├── cluster-autoscaler.yaml ├── cluster-filler.yaml ├── cluster-monitoring-configmap.yaml ├── create-autoscalers.sh ├── htpasswd ├── htpasswd-cr.yaml ├── job-work-queue.yaml ├── logging-cr.yaml ├── logging-project.yaml └── machine-autoscale-example.yaml ├── docs ├── 01-prerequisites.md ├── 02-install.md ├── 03-explore.md ├── 04-scaling-cluster.md ├── 05-infrastructure-nodes.md ├── 06-authentication.md ├── 07-extensions.md ├── 08-logging.md ├── 09-istio.md ├── 97-tips-and-tricks.md ├── 98-cleanup.md └── 99-troubleshooting.md └── img ├── all-systems.png ├── grafana.png ├── machine-set.png └── scale-nodes.png /.gitignore: -------------------------------------------------------------------------------- 1 | *.swp 2 | *.swo 3 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # OpenShift 4 (beta) on AWS 2 | This tutorial walks you through setting up OpenShift the easy way. This guide 3 | is for people looking for a fully automated command to bring up a 4 | self-managed pre-release (beta) OpenShift 4 cluster on Amazon AWS. 5 | 6 | > The results of this tutorial should not be viewed as production ready. 7 | 8 | ## Target Audience 9 | 10 | The target audience for this tutorial is a user looking to install and 11 | operate a pre-release OpenShift 4 cluster for early access, who wants to 12 | understand how everything fits together. 13 | 14 | ## Cluster Details 15 | 16 | This document guides you through creating a highly available OpenShift 17 | cluster on AWS. 18 | 19 | ## Documentation 20 | With the third beta drop of OpenShift 4, this repository will link you to the 21 | work-in-progress official documentation. Currently that documentation is 22 | behind a user/password (for anti-search-engine-indexing purposes. 23 | 24 | ``` 25 | Username: stage-user 26 | Password: zc9$!9S%&0N9hsBVSN42 27 | ``` 28 | 29 | ## Bugs vs. Cases 30 | As this is pre-release software, it is completely unsupported, and you should 31 | not open support cases for any issues you encounter. However, we very much 32 | wish to collect feedback on documentation and other product issues. Should 33 | you encounter a problem, feel free to [file a 34 | bug](https://bugzilla.redhat.com/enter_bug.cgi?product=OpenShift%20Container%20Platform). 35 | 36 | ## Exercises 37 | 38 | This tutorial assumes you have familiarity with Amazon AWS. 39 | 40 | * [Prerequisites](docs/01-prerequisites.md) 41 | * [Installing the Cluster](docs/02-install.md) 42 | * [Exploring the Cluster](docs/03-explore.md) 43 | * [Scaling the Cluster](docs/04-scaling-cluster.md) 44 | * [Infrastructure Nodes](docs/05-infrastructure-nodes.md) 45 | * [Authentication](docs/06-authentication.md) 46 | * [Operator Extensions](docs/07-extensions.md) 47 | * [Tips and tricks](docs/97-tips-and-tricks.md) 48 | * [Cleaning Up](docs/98-cleanup.md) 49 | * [Troubleshooting](docs/99-troubleshooting.md) 50 | -------------------------------------------------------------------------------- /assets/cb-example-auth.yaml: -------------------------------------------------------------------------------- 1 | apiVersion: v1 2 | data: 3 | password: c2VjdXJlcGFzc3dvcmQ= 4 | username: Y291Y2hiYXNl 5 | kind: Secret 6 | metadata: 7 | name: cb-example-auth 8 | namespace: mycouchbase 9 | type: Opaque 10 | -------------------------------------------------------------------------------- /assets/cluster-autoscaler.yaml: -------------------------------------------------------------------------------- 1 | apiVersion: "autoscaling.openshift.io/v1" 2 | kind: "ClusterAutoscaler" 3 | metadata: 4 | name: "default" 5 | spec: 6 | resourceLimits: 7 | maxNodesTotal: 20 8 | scaleDown: 9 | enabled: true 10 | delayAfterAdd: 10s 11 | delayAfterDelete: 10s 12 | delayAfterFailure: 10s 13 | -------------------------------------------------------------------------------- /assets/cluster-filler.yaml: -------------------------------------------------------------------------------- 1 | apiVersion: apps/v1 2 | kind: Deployment 3 | metadata: 4 | name: cluster-filler-deployment 5 | labels: 6 | app: cluster-filler-deployment 7 | spec: 8 | replicas: 1 9 | selector: 10 | matchLabels: 11 | app: cluster-filler-deployment 12 | template: 13 | metadata: 14 | labels: 15 | app: cluster-filler-deployment 16 | spec: 17 | containers: 18 | - name: sleep-test-container 19 | image: rhel7 20 | command: [ "/bin/bash", "-c", "--" ] 21 | args: [ "while true; do sleep 30; done;" ] 22 | nodeSelector: 23 | cluster: filler 24 | -------------------------------------------------------------------------------- /assets/cluster-monitoring-configmap.yaml: -------------------------------------------------------------------------------- 1 | apiVersion: v1 2 | kind: ConfigMap 3 | metadata: 4 | name: cluster-monitoring-config 5 | namespace: openshift-monitoring 6 | data: 7 | config.yaml: |+ 8 | alertmanagerMain: 9 | nodeSelector: 10 | node-role.kubernetes.io/infra: "" 11 | prometheusK8s: 12 | nodeSelector: 13 | node-role.kubernetes.io/infra: "" 14 | prometheusOperator: 15 | nodeSelector: 16 | node-role.kubernetes.io/infra: "" 17 | grafana: 18 | nodeSelector: 19 | node-role.kubernetes.io/infra: "" 20 | k8sPrometheusAdapter: 21 | nodeSelector: 22 | node-role.kubernetes.io/infra: "" 23 | kubeStateMetrics: 24 | nodeSelector: 25 | node-role.kubernetes.io/infra: "" 26 | telemeterClient: 27 | nodeSelector: 28 | node-role.kubernetes.io/infra: "" 29 | 30 | 31 | -------------------------------------------------------------------------------- /assets/create-autoscalers.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | export AUTOSCALER_JSON='{"apiVersion":"autoscaling.openshift.io/v1alpha1","kind":"MachineAutoscaler","metadata":{"name":"worker","namespace":"openshift-machine-api"},"spec":{"minReplicas":1,"maxReplicas":4,"scaleTargetRef":{"apiVersion":"machine.openshift.io/v1beta1","kind":"MachineSet","name":"worker"}}}' 4 | export MACHINESETS=$(oc get machineset -n openshift-machine-api -o json | jq '.items[]|.metadata.name' -r ) 5 | 6 | for ms in $MACHINESETS 7 | do 8 | NAME="autoscale-$ms" 9 | echo $AUTOSCALER_JSON | name=$NAME ms=$ms jq '.metadata.name=env["name"] | .spec.scaleTargetRef.name=env["ms"]' | oc create -f - 10 | done 11 | -------------------------------------------------------------------------------- /assets/htpasswd: -------------------------------------------------------------------------------- 1 | susan:$apr1$cwuRPkjz$CiYbJVLmwZDTQrz19ve58. 2 | john:$apr1$cwuRPkjz$CiYbJVLmwZDTQrz19ve58. 3 | ramses:$apr1$cwuRPkjz$CiYbJVLmwZDTQrz19ve58. 4 | elise:$apr1$cwuRPkjz$CiYbJVLmwZDTQrz19ve58. -------------------------------------------------------------------------------- /assets/htpasswd-cr.yaml: -------------------------------------------------------------------------------- 1 | apiVersion: config.openshift.io/v1 2 | kind: OAuth 3 | metadata: 4 | name: cluster 5 | spec: 6 | identityProviders: 7 | - name: my_htpasswd_provider 8 | challenge: true 9 | login: true 10 | mappingMethod: claim 11 | type: HTPasswd 12 | htpasswd: 13 | fileData: 14 | name: htpass-secret -------------------------------------------------------------------------------- /assets/job-work-queue.yaml: -------------------------------------------------------------------------------- 1 | apiVersion: batch/v1 2 | kind: Job 3 | metadata: 4 | generateName: work-queue- 5 | spec: 6 | template: 7 | spec: 8 | containers: 9 | - name: work 10 | image: busybox 11 | command: ["sleep", "300"] 12 | resources: 13 | requests: 14 | memory: 500Mi 15 | cpu: 500m 16 | restartPolicy: Never 17 | backoffLimit: 4 18 | completions: 50 19 | parallelism: 50 -------------------------------------------------------------------------------- /assets/logging-cr.yaml: -------------------------------------------------------------------------------- 1 | apiVersion: "logging.openshift.io/v1alpha1" 2 | kind: "ClusterLogging" 3 | metadata: 4 | name: "instance" 5 | namespace: "openshift-logging" 6 | spec: 7 | managementState: "Managed" 8 | logStore: 9 | type: "elasticsearch" 10 | elasticsearch: 11 | nodeCount: 3 12 | storage: {} 13 | redundancyPolicy: "SingleRedundancy" 14 | nodeSelector: 15 | node-role.kubernetes.io/infra: "" 16 | resources: 17 | request: 18 | memory: 4G 19 | visualization: 20 | type: "kibana" 21 | kibana: 22 | replicas: 1 23 | nodeSelector: 24 | node-role.kubernetes.io/infra: "" 25 | curation: 26 | type: "curator" 27 | curator: 28 | schedule: "30 3 * * *" 29 | nodeSelector: 30 | node-role.kubernetes.io/infra: "" 31 | collection: 32 | logs: 33 | type: "fluentd" 34 | fluentd: {} 35 | nodeSelector: 36 | node-role.kubernetes.io/infra: "" -------------------------------------------------------------------------------- /assets/logging-project.yaml: -------------------------------------------------------------------------------- 1 | apiVersion: v1 2 | kind: Namespace 3 | metadata: 4 | name: openshift-logging 5 | annotations: 6 | openshift.io/node-selector: "" 7 | labels: 8 | openshift.io/cluster-logging: "true" 9 | openshift.io/cluster-monitoring: "true" 10 | -------------------------------------------------------------------------------- /assets/machine-autoscale-example.yaml: -------------------------------------------------------------------------------- 1 | kind: List 2 | metadata: {} 3 | apiVersion: v1 4 | items: 5 | - apiVersion: "autoscaling.openshift.io/v1beta1" 6 | kind: "MachineAutoscaler" 7 | metadata: 8 | generateName: autoscale-- 9 | namespace: "openshift-machine-api" 10 | spec: 11 | minReplicas: 1 12 | maxReplicas: 4 13 | scaleTargetRef: 14 | apiVersion: machine.openshift.io/v1beta1 15 | kind: MachineSet 16 | name: -worker- 17 | - apiVersion: "autoscaling.openshift.io/v1beta1" 18 | kind: "MachineAutoscaler" 19 | metadata: 20 | generateName: autoscale-- 21 | namespace: "openshift-machine-api" 22 | spec: 23 | minReplicas: 1 24 | maxReplicas: 4 25 | scaleTargetRef: 26 | apiVersion: machine.openshift.io/v1beta1 27 | kind: MachineSet 28 | name: -worker- 29 | - apiVersion: "autoscaling.openshift.io/v1beta1" 30 | kind: "MachineAutoscaler" 31 | metadata: 32 | generateName: autoscale-- 33 | namespace: "openshift-machine-api" 34 | spec: 35 | minReplicas: 1 36 | maxReplicas: 4 37 | scaleTargetRef: 38 | apiVersion: machine.openshift.io/v1beta1 39 | kind: MachineSet 40 | name: -worker- 41 | -------------------------------------------------------------------------------- /docs/01-prerequisites.md: -------------------------------------------------------------------------------- 1 | # Red Hat Developers 2 | Access to some of the installation web resources requires a Red Hat customer 3 | portal account that is associated with the Red Hat Developer program. Make 4 | sure to visit https://developers.redhat.com and log-in with your customer 5 | portal account and accept the Developer program Ts&Cs. 6 | 7 | # Configuring an AWS Account 8 | Refer to the [Configuring an AWS 9 | account](https://docs.openshift.com/container-platform/4.0/installing/installing_aws/installing-aws-account.html) 10 | documentation. 11 | 12 | Next: [Installing the Cluster](02-install.md) -------------------------------------------------------------------------------- /docs/02-install.md: -------------------------------------------------------------------------------- 1 | # Installing on AWS Quickly 2 | Refer to the [Installing a cluster quickly on 3 | AWS](https://docs.openshift.com/container-platform/4.0/installing/installing_aws/installing-aws-default.html#installing-aws-default) 4 | documentation. 5 | 6 | # Customized Installation 7 | It is possible to customize some of the options for the installation on AWS. 8 | The extent of that customization is covered in the [customized installation 9 | documentation](https://docs.openshift.com/container-platform/4.0/installing/installing_aws/installing-aws-customizations.html). 10 | 11 | # Problems? 12 | If at any point you run into issues while exploring OpenShift 4, see the 13 | [troubleshooting](99-troubleshooting.md) section. 14 | 15 | Next: [Exploring the Cluster](03-explore.md) 16 | -------------------------------------------------------------------------------- /docs/03-explore.md: -------------------------------------------------------------------------------- 1 | # Exploring OpenShift 4 2 | The following instructions assume that you have deployed the cluster using the 3 | *openshift-install* tooling, and that the necessary configuration files required 4 | for cluster interaction have been automatically generated for you in your home 5 | directory. If you have been provided with access to an environment (e.g. it has 6 | been deployed for you) or you do **not** have the necessary configuration files 7 | generated, follow these steps; it requires that you have the credentials and API 8 | URI information to hand: 9 | 10 | ~~~bash 11 | $ oc login --server 12 | 13 | The server uses a certificate signed by an unknown authority. 14 | You can bypass the certificate check, but any data you send to the server could be intercepted by others. 15 | Use insecure connections? (y/n): y 16 | 17 | Authentication required for https://api.beta-190305-1.ocp4testing.openshiftdemos.com:6443 (openshift) 18 | Username: 19 | Password: 20 | Login successful. 21 | (...) 22 | 23 | Using project "default". 24 | Welcome! See 'oc help' to get started. 25 | ~~~ 26 | 27 | You can now check that your config has been written successfully: 28 | 29 | ~~~bash 30 | $ cat ~/.kube/config 31 | apiVersion: v1 32 | clusters: 33 | - cluster: 34 | insecure-skip-tls-verify: true 35 | server: https://api.beta-190305-1.ocp4testing.openshiftdemos.com:6443 36 | (...) 37 | ~~~ 38 | 39 | > **NOTE**: Your output will vary slightly from the above, you'll just need to 40 | make sure to use the API endpoint and credentials that you were provided with. 41 | 42 | Now that your cluster is installed, you will have access to the web console and 43 | can use the CLI. Below are some command-line exercises to explore the cluster. 44 | 45 | ## Cluster Nodes 46 | 47 | The default installation behavior creates 6 nodes: 3 masters and 3 "worker" 48 | application/compute nodes. You can view them with: 49 | 50 | ~~~bash 51 | $ oc get nodes -o wide 52 | NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME 53 | ip-10-0-137-104.ec2.internal Ready worker 24h v1.12.4+5dc94f3fda 10.0.137.104 Red Hat CoreOS 400.7.20190301.0 3.10.0-957.5.1.el7.x86_64 cri-o://1.12.6-1.rhaos4.0.git2f0cb0d.el7 54 | ip-10-0-140-138.ec2.internal Ready master 24h v1.12.4+5dc94f3fda 10.0.140.138 Red Hat CoreOS 400.7.20190301.0 3.10.0-957.5.1.el7.x86_64 cri-o://1.12.6-1.rhaos4.0.git2f0cb0d.el7 55 | ip-10-0-158-222.ec2.internal Ready master 24h v1.12.4+5dc94f3fda 10.0.158.222 Red Hat CoreOS 400.7.20190301.0 3.10.0-957.5.1.el7.x86_64 cri-o://1.12.6-1.rhaos4.0.git2f0cb0d.el7 56 | ip-10-0-159-179.ec2.internal Ready worker 24h v1.12.4+5dc94f3fda 10.0.159.179 Red Hat CoreOS 400.7.20190301.0 3.10.0-957.5.1.el7.x86_64 cri-o://1.12.6-1.rhaos4.0.git2f0cb0d.el7 57 | ip-10-0-168-43.ec2.internal Ready master 24h v1.12.4+5dc94f3fda 10.0.168.43 Red Hat CoreOS 400.7.20190301.0 3.10.0-957.5.1.el7.x86_64 cri-o://1.12.6-1.rhaos4.0.git2f0cb0d.el7 58 | ip-10-0-171-135.ec2.internal Ready worker 24h v1.12.4+5dc94f3fda 10.0.171.135 Red Hat CoreOS 400.7.20190301.0 3.10.0-957.5.1.el7.x86_64 cri-o://1.12.6-1.rhaos4.0.git2f0cb0d.el7 59 | ~~~ 60 | 61 | If you want to see the various applied **labels**, you can also do: 62 | 63 | ~~~bash 64 | $ oc get nodes --show-labels 65 | NAME STATUS ROLES AGE VERSION LABELS 66 | ip-10-0-137-104.ec2.internal Ready worker 23h v1.12.4+5dc94f3fda beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=m4.large,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=us-east-1,failure-domain.beta.kubernetes.io/zone=us-east-1a,kubernetes.io/hostname=ip-10-0-137-104,node-role.kubernetes.io/worker= 67 | ip-10-0-140-138.ec2.internal Ready master 23h v1.12.4+5dc94f3fda beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=m4.xlarge,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=us-east-1,failure-domain.beta.kubernetes.io/zone=us-east-1a,kubernetes.io/hostname=ip-10-0-140-138,node-role.kubernetes.io/master= 68 | ip-10-0-158-222.ec2.internal Ready master 23h v1.12.4+5dc94f3fda beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=m4.xlarge,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=us-east-1,failure-domain.beta.kubernetes.io/zone=us-east-1b,kubernetes.io/hostname=ip-10-0-158-222,node-role.kubernetes.io/master= 69 | ip-10-0-159-179.ec2.internal Ready worker 23h v1.12.4+5dc94f3fda beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=m4.large,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=us-east-1,failure-domain.beta.kubernetes.io/zone=us-east-1b,kubernetes.io/hostname=ip-10-0-159-179,node-role.kubernetes.io/worker= 70 | ip-10-0-168-43.ec2.internal Ready master 23h v1.12.4+5dc94f3fda beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=m4.xlarge,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=us-east-1,failure-domain.beta.kubernetes.io/zone=us-east-1c,kubernetes.io/hostname=ip-10-0-168-43,node-role.kubernetes.io/master= 71 | ip-10-0-171-135.ec2.internal Ready worker 23h v1.12.4+5dc94f3fda beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=m4.large,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=us-east-1,failure-domain.beta.kubernetes.io/zone=us-east-1c,kubernetes.io/hostname=ip-10-0-171-135,node-role.kubernetes.io/worker= 72 | ~~~ 73 | 74 | For reference, **labels** are used as a mechanism to tag certain information 75 | onto a node, or a set of nodes, that can help you identify your systems, e.g. 76 | by operating system, system architecture, specification, location of the system 77 | (e.g. region), it's hostname, etc. They can also help with application 78 | scheduling, e.g. make sure that my application (or pod) resides on a specific 79 | system type. The labels shown above are utilising the default labels, but it's 80 | possible to set some custom labels in the form of a key-value pair. 81 | 82 | ## The Cluster Operator 83 | 84 | The cluster version operator is the core of what defines an OpenShift 85 | deployment. The cluster version operator pod(s) contains the set of manifests 86 | which are used to deploy, updated, and/or manage the OpenShift services in 87 | the cluster. This operator ensures that the other services, also deployed as 88 | operators, are at the version which matches the release definition and takes 89 | action to remedy discrepancies when necessary. 90 | 91 | ~~~bash 92 | $ oc get deployments -n openshift-cluster-version 93 | NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 94 | cluster-version-operator 1 1 1 1 2h 95 | ~~~ 96 | 97 | You can also view the current version of the OpenShift cluster and give you 98 | a high-level indication of the status: 99 | 100 | ~~~bash 101 | $ oc get clusterversion 102 | NAME VERSION AVAILABLE PROGRESSING SINCE STATUS 103 | version 4.0.0-0.8 True False 133m Cluster version is 4.0.0-0.8 104 | ~~~ 105 | 106 | If you want to review a list of operators that the cluster version operator is 107 | controlling, along with their status, you can ask for a list of the cluster 108 | operators: 109 | 110 | ~~~bash 111 | $ oc get clusteroperator 112 | NAME VERSION AVAILABLE PROGRESSING FAILING SINCE 113 | cluster-autoscaler True False False 29h 114 | cluster-storage-operator True False False 29h 115 | console True False False 28h 116 | dns True False False 29h 117 | image-registry True False False 29h 118 | ingress True False False 28h 119 | kube-apiserver True False False 29h 120 | kube-controller-manager True False False 29h 121 | kube-scheduler True False False 29h 122 | machine-api True False False 29h 123 | machine-config True False False 17h 124 | marketplace-operator True False False 29h 125 | monitoring True False False 80m 126 | network True False False 81m 127 | node-tuning True False False 28h 128 | openshift-apiserver True False False 81m 129 | openshift-authentication True False False 29h 130 | openshift-cloud-credential-operator True False False 29h 131 | openshift-controller-manager True False False 29h 132 | openshift-samples True False False 29h 133 | operator-lifecycle-manager True False False 29h 134 | ~~~ 135 | 136 | Or a more comprehensive way of getting a list of operators running on the 137 | cluster, along with the link to the code, the documentation, and the commit that 138 | provided the functionality is as follows: 139 | 140 | ~~~bash 141 | oc adm release info --commits 142 | ~~~ 143 | 144 | You will see something like: 145 | 146 | ``` 147 | Name: 4.0.0-0.8 148 | Digest: sha256:358585fa0d2e709ce3964a245474b49b4360d8946455ab5b0467a11b135a21df 149 | Created: 2019-03-25 03:49:04 +0000 UTC 150 | OS/Arch: linux/amd64 151 | Manifests: 260 152 | 153 | Release Metadata: 154 | Version: 4.0.0-0.8 155 | Upgrades: 156 | 157 | Component Versions: 158 | Kubernetes 1.12.4 159 | 160 | Images: 161 | NAME REPO COMMIT 162 | aws-machine-controllers https://github.com/openshift/cluster-api-provider-aws 995e3e2a6d2b4a06ca07a61279b2131b1e487344 163 | cli https://github.com/openshift/ose 461e7d39741f996fad13203ccdc8c1a55ad6c44a 164 | cloud-credential-operator https://github.com/openshift/cloud-credential-operator 2560a997b6712c240339a92109780ea36b9cf30f 165 | ... 166 | ``` 167 | 168 | You can also `rsh` (remote shell access) into the running Operator and see the 169 | various manifests associated with the installed release of OpenShift: 170 | 171 | ~~~bash 172 | oc rsh -n openshift-cluster-version deployments/cluster-version-operator 173 | ~~~ 174 | 175 | Then to list the available manifests: 176 | 177 | ~~~bash 178 | ls -l /release-manifests/ 179 | ~~~ 180 | 181 | You will see something like: 182 | 183 | ``` 184 | total 1224 185 | -r--r--r--. 1 root root 5322 Mar 22 10:21 0000_05_config-operator_01_apiserver.crd.yaml 186 | -r--r--r--. 1 root root 5831 Mar 22 10:21 0000_05_config-operator_01_authentication.crd.yaml 187 | -r--r--r--. 1 root root 6941 Mar 22 10:21 0000_05_config-operator_01_build.crd.yaml 188 | -r--r--r--. 1 root root 2647 Mar 22 10:21 0000_05_config-operator_01_console.crd.yaml 189 | ... 190 | ~~~ 191 | 192 | You will see a number of `.yaml` files in this directory; these are manifests 193 | that describe each of the operators and how they're applied. Feel free to take a 194 | look at some of these to give you an idea of what it's doing. 195 | 196 | ~~~bash 197 | cat /release-manifests/0000_70_console-operator_00-crd.yaml 198 | ~~~ 199 | 200 | You will see something like: 201 | 202 | ``` 203 | apiVersion: apiextensions.k8s.io/v1beta1 204 | kind: CustomResourceDefinition 205 | metadata: 206 | name: consoles.console.openshift.io 207 | spec: 208 | group: console.openshift.io 209 | names: 210 | kind: Console 211 | listKind: ConsoleList 212 | plural: consoles 213 | singular: console 214 | scope: Namespaced 215 | version: v1alpha1 216 | ``` 217 | 218 | > **NOTE**: Don't forget to `exit` from your`rsh` session before continuing... 219 | 220 | If you want to look at what the Cluster Operator has done since it was launched, 221 | you can execute the following: 222 | 223 | ~~~bash 224 | oc logs deployments/cluster-version-operator -n openshift-cluster-version > operatorlog.txt 225 | head operatorlog.txt 226 | ~~~ 227 | 228 | You will see something like: 229 | 230 | ~~~ 231 | I0306 10:28:10.548869 1 start.go:71] ClusterVersionOperator v4.0.0-0.139.0.0-dirty 232 | I0306 10:28:10.601159 1 start.go:197] Using in-cluster kube client config 233 | I0306 10:28:10.667401 1 leaderelection.go:185] attempting to acquire leader lease openshift-cluster-version/version... 234 | ... 235 | ~~~ 236 | 237 | The operator's log is **extremely** long, so it is recommended that you redirect 238 | it to a file instead of trying to look at it directly with the `logs` command. 239 | 240 | # Exploring RHEL CoreOS 241 | *WARNING* this requires advanced knowledge of EC2 and is not a thourough set 242 | of instructions. 243 | 244 | The latest installer does not create any public IP addresses for any of the 245 | EC2 instances that it provisions for your OpenShift cluster. In order to be 246 | able to SSH to your OpenShift 4 hosts: 247 | 248 | 1. Create a security group that allows SSH access into the VPC created by the 249 | installer 250 | 1. Create an EC2 instance yourself: 251 | * inside the VPC that the installer created 252 | * on one of the public subnets the installer created 253 | 1. Associate a public IP address with the EC2 instance that you created. 254 | 255 | Unlike with the OpenShift installation, you must associate the EC2 instance 256 | you create with an SSH keypair that you already have access to. 257 | 258 | It does not matter what OS you choose for this instance, as it will simply 259 | serve as an SSH bastion to bridge the internet into your OCP VPC. 260 | 261 | Once you have provisioned your EC2 instance and can SSH into it, you will 262 | then need to add the SSH key that you associated with your OCP installation 263 | (**not the key for the bastion instance**). At that point you can follow the 264 | rest of the instructions. 265 | 266 | ## Cluster Makeup 267 | The OpenShift 4 cluster is made of hosts that are running RHEL CoreOS. 268 | CoreOS is a container optimized, hardened, minimal footprint operating system 269 | designed specifically to work with OpenShift and to run containers. 270 | 271 | ## Find a Hostname 272 | First, look at the output of `oc get nodes` and pick one of the nodes that is 273 | a master. Its name is something like `ip-10-0-1-163.ec2.internal`. 274 | 275 | From the bastion SSH host you manually deployed into EC2, you can then SSH 276 | into that master host, making sure to use the same SSH key you specified 277 | during the installation: 278 | 279 | ssh -i /path/to/sshkey core@MASTER_HOSTNAME_FROM_ABOVE 280 | 281 | **Note: you *must* use the `core` user**. 282 | 283 | If it works, you'll see the CoreOS MOTD/prompt: 284 | 285 | Red Hat CoreOS 400.7.20190301.0 Beta 286 | WARNING: Direct SSH access to machines is not recommended. 287 | This node has been annotated with machineconfiguration.openshift.io/ssh=accessed 288 | 289 | --- 290 | [core@ip-10-0-135-32 ~]$ 291 | 292 | ## Explore RHEL CoreOS 293 | You can check the kernel information with the following: 294 | 295 | uname -rs 296 | 297 | You will see something like: 298 | 299 | Linux 3.10.0-957.5.1.el7.x86_64 300 | 301 | The following command will show you a little bit about how `Ignition` 302 | contacts remote servers for information and etc: 303 | 304 | journalctl --no-pager|grep "Ignition finished successfully" -B 100 305 | 306 | RHEL CoreOS is an immutable operating system. It is predominantly a 307 | read-only image-based OS. Try to create a file: 308 | 309 | touch /usr/test 310 | 311 | You will see that you cannot because the FS is read only. However, there is a 312 | place that is writable, but it is only writable by a user with privileges 313 | (not `core`). As the `core` user, attempt to write to `/var/`: 314 | 315 | touch /var/test 316 | 317 | You will be denied because of permissions. However, if you use `sudo`, it 318 | will work: 319 | 320 | sudo touch /var/test && ls -l /var/test* 321 | 322 | SELinux is enforcing: 323 | 324 | sestatus 325 | 326 | You will see something like: 327 | 328 | SELinux status: enabled 329 | SELinuxfs mount: /sys/fs/selinux 330 | SELinux root directory: /etc/selinux 331 | Loaded policy name: targeted 332 | Current mode: enforcing 333 | Mode from config file: enforcing 334 | Policy MLS status: enabled 335 | Policy deny_unknown status: allowed 336 | Max kernel policy version: 31 337 | 338 | The following commands will show you more information about the core of 339 | OpenShift: 340 | 341 | systemctl status kubelet 342 | systemctl status crio 343 | sudo crictl pods 344 | 345 | During the bootstrapping process, we need to run containers, but OpenShift's 346 | core (eg: kubelet) is still not there yet. To accomplish that, `podman` is 347 | used. You can explore `podman` a little: 348 | 349 | podman version 350 | 351 | ## Web Console 352 | It may take several minutes for the OpenShift web console to become 353 | available/reachable after the installation completes. But, be sure to visit 354 | it when it does. You can find the URL for the web console for your installed 355 | cluster in the output of the installer. For example: 356 | 357 | https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com 358 | 359 | ### Note 360 | When visiting the web console you will receive a certificate error in your 361 | browser. This is because the installation uses a self-signed certificate. You 362 | will need to accept it in order to continue. 363 | 364 | ### Note 365 | If you lose either the password or the console URL, you can find them in the 366 | `.openshift_install.log` file which is likely in the same folder in which you executed 367 | `openshift-install` (or the dir that you specified). For example: 368 | 369 | tail -n5 /path/to/dir/.openshift_install.log 370 | 371 | ### Note 372 | If you open another terminal or log-out and log-in to the terminal again and 373 | lose your `KUBECONFIG` environment variable, look for the `auth/kubeconfig` 374 | file in your installation artifacts directory and simply re-export it: 375 | 376 | export KUBECONFIG=/path/to/something/auth/kubeconfig 377 | 378 | Next: [Scaling the Cluster](04-scaling-cluster.md) 379 | -------------------------------------------------------------------------------- /docs/04-scaling-cluster.md: -------------------------------------------------------------------------------- 1 | # Scaling an OpenShift 4 Cluster 2 | With OpenShift 4.0+, we now have the ability to dynamically scale the cluster 3 | size through OpenShift itself. 4 | 5 | Refer to the [Manually scaling a 6 | MachineSet](https://docs.openshift.com/container-platform/4.0/machine_management/manually-scaling-machineset.html) 7 | documentation for details on how to do this from the command line. 8 | 9 | # Cluster Scaling From the Web Console 10 | 11 | You can also scale the cluster from the Web Console. 12 | 13 | 1. Go to the OpenShift web console and login with `kubeadmin` (or your admin 14 | username if different) 15 | 1. Browse to `Machines` on the left-hand side-bar, and click `Machine Sets`. 16 | 1. On the `Machine Sets` page, select `openshift-machine-api` from the `Project` 17 | dropdown and you should see the machine sets: 18 | 19 |
20 | 21 | 1. Select one of the machine sets in the list by clicking on the name, e.g. 22 | "**beta-190305-1-79tf5-worker-us-east-1a**" (yours will be slightly different) 23 | 1. Go to the OpenShift web console and login with `kubeadmin`. 24 | 1. Browse to `Machines` in the side-bar, and click `Machine Sets`. 25 | 1. On the `Machine Sets` page, select `openshift-machine-api` from the 26 | `Project` dropdown. 27 | 1. Select a worker set to scale by clicking it. 28 | 29 | Depending on the AWS region you chose, you may have several worker machine 30 | sets that can be scaled, some of which are at a scale of 0. It does not 31 | matter which set you choose for this example. 32 | 1. In the `Actions` pull down menu (on the right hand side), select `Edit Count` 33 | 34 | 1. Enter '3' and click `Save` 35 | 36 |
37 | 38 | At this point you can click the `Machines` tab in this `Machine Set` display 39 | and see the allocated machines. The `Overview` tab will let you know when the 40 | machines become ready. If you click `Machine Sets` under `Machines` on the 41 | left-hand side again, you will also see the status of the machines in the set: 42 | 43 |
44 | 45 | machines become ready. If you click `Machine Sets` under `Machines` 46 | again, you will also see the status of the machines in the set. 47 | 48 | It will take several minutes for the new machines to become ready. In the 49 | background additional EC2 instances are being provisioned and then registered 50 | and configured to participate in the cluster, so yours may still show 1/3. 51 | 52 | You can also view this in the CLI: 53 | 54 | ~~~bash 55 | $ oc get machinesets -n openshift-machine-api 56 | NAME DESIRED CURRENT READY AVAILABLE AGE 57 | beta-190305-1-79tf5-worker-us-east-1a 3 3 3 3 23h 58 | beta-190305-1-79tf5-worker-us-east-1b 1 1 1 1 23h 59 | beta-190305-1-79tf5-worker-us-east-1c 1 1 1 1 23h 60 | beta-190305-1-79tf5-worker-us-east-1d 0 0 23h 61 | beta-190305-1-79tf5-worker-us-east-1e 0 0 23h 62 | beta-190305-1-79tf5-worker-us-east-1f 0 0 23h 63 | 64 | $ oc get nodes 65 | NAME STATUS ROLES AGE VERSION 66 | ip-10-0-132-138.ec2.internal Ready worker 2m6s v1.12.4+5dc94f3fda 67 | ip-10-0-137-104.ec2.internal Ready worker 23h v1.12.4+5dc94f3fda 68 | ip-10-0-140-138.ec2.internal Ready master 24h v1.12.4+5dc94f3fda 69 | ip-10-0-140-67.ec2.internal Ready worker 2m6s v1.12.4+5dc94f3fda 70 | ip-10-0-158-222.ec2.internal Ready master 24h v1.12.4+5dc94f3fda 71 | ip-10-0-159-179.ec2.internal Ready worker 23h v1.12.4+5dc94f3fda 72 | ip-10-0-168-43.ec2.internal Ready master 24h v1.12.4+5dc94f3fda 73 | ip-10-0-171-135.ec2.internal Ready worker 23h v1.12.4+5dc94f3fda 74 | ~~~ 75 | 76 | You'll note that some of these systems 'age' will be much newer than some of the 77 | others, these are the ones that will have just been added in. Before continuing, 78 | scale back down by editing the count to whatever it was previously for the 79 | `Machine Set`, i.e. return it to '1' node. 80 | 81 | ## Note 82 | The default installation currently creates two routers, but they are on the 83 | same host. This is a known bug. It is possible that when you scale down your 84 | cluster that you may inadvertently end up removing the node where the router 85 | was running, which will temporarily make the console and other resources 86 | unavailable. If you suddenly lose access to the web console, wait a few 87 | moments, and then check to see the status of the router pod with: 88 | 89 | ~~~bash 90 | $ oc get pod -n openshift-ingress 91 | NAME READY STATUS RESTARTS AGE 92 | router-default-dffd8548-6g4hz 1/1 Running 0 23h 93 | router-default-dffd8548-vxtt8 1/1 Running 0 23h 94 | ~~~ 95 | 96 | If there is no router pod, or if it is in the `ContainerCreating` state, wait 97 | a little longer. 98 | 99 | # Automatic Cluster Scale Up 100 | 101 | OpenShift can automatically scale the infrastructure based on workload provided 102 | there is a configuration specified to do so. Before we begin, ensure that your 103 | cluster is back to having three nodes running: 104 | 105 | ~~~bash 106 | $ oc get machinesets -n openshift-machine-api 107 | NAME DESIRED CURRENT READY AVAILABLE AGE 108 | beta-190305-1-79tf5-worker-us-east-1a 1 1 1 1 24h 109 | beta-190305-1-79tf5-worker-us-east-1b 1 1 1 1 24h 110 | beta-190305-1-79tf5-worker-us-east-1c 1 1 1 1 24h 111 | beta-190305-1-79tf5-worker-us-east-1d 0 0 24h 112 | beta-190305-1-79tf5-worker-us-east-1e 0 0 24h 113 | beta-190305-1-79tf5-worker-us-east-1f 0 0 24h 114 | ~~~ 115 | 116 | ## Auto Scaling Configuration 117 | 118 | Refer to the [Applying 119 | autoscaling](https://docs.openshift.com/container-platform/4.0/machine_management/applying-autoscaling.html) 120 | documentation for details on how to configure the cluster for autoscaling. 121 | 122 | ### NOTE 123 | You can find an example cluster autoscaler config here: 124 | 125 | https://raw.githubusercontent.com/openshift/training/master/assets/cluster-autoscaler.yaml 126 | 127 | Feel free to adjust the maximum number of nodes as desired. 128 | 129 | ### NOTE 130 | You can also use this script to automagically create one cluster autoscaler 131 | for EVERY `MachineSet` you currently have: 132 | 133 | https://raw.githubusercontent.com/openshift/training/master/assets/create-autoscalers.sh 134 | 135 | It requires the `jq` program. 136 | 137 | # Causing a Scaling Event 138 | This next section walks through causing the cluster to auto scale. 139 | 140 | ## Define a `Job` 141 | 142 | The following example YAML file defines a `Job`: 143 | 144 | https://raw.githubusercontent.com/openshift/training/master/assets/job-work-queue.yaml 145 | 146 | It will produce a massive load that the cluster cannot handle, and will force 147 | the autoscaler to take action (up to the `maxReplicas` defined in your 148 | ClusterAutoscaler YAML). 149 | 150 | > **NOTE**: If you did not scale down your machines earlier, you may have too 151 | much capacity to trigger an autoscaling event. Make sure you have no more than 152 | 3 total workers before continuing. 153 | 154 | Create a project to hold the resources for the `Job`, and switch into it: 155 | 156 | ~~~bash 157 | oc adm new-project autoscale-example && oc project autoscale-example 158 | ~~~ 159 | 160 | ## Open Grafana 161 | In the OpenShift web console, click `Monitoring` and then click `Dashboards`. 162 | This will open a new browser tab for Grafana. You will also get a certificate 163 | error similar to the first time you logged in. This is because Grafana has 164 | its own SSL certificate. You will then see a login button. Grafana is 165 | configured to use an OpenShift user and inherits permissions of that user for 166 | accessing cluster information. This happens to be the user you're already 167 | logged into the web console with. 168 | 169 | Finally, allow the permissions, and then you will see the Grafana homepage. 170 | 171 | Click the dropdown on `Home` and choose `Kubernetes / Compute Resources / 172 | Cluster`. Leave this browser window open while you start the `Job` so that 173 | you can observe the CPU utilization of the cluster rise: 174 | 175 |
176 | 177 | ## Force an Autoscaling Event 178 | 179 | Now we're ready to create the `Job`: 180 | 181 | ~~~bash 182 | oc create -n autoscale-example -f https://raw.githubusercontent.com/openshift/training/master/assets/job-work-queue.yaml 183 | ~~~ 184 | 185 | You will see a note that the `Job` was created. It will create a *lot* of `Pods`. You can look at the list of pods with: 186 | 187 | ``` 188 | oc get pod -n autoscale-example 189 | ``` 190 | 191 | After a few moments, look at the list of `Machines`: 192 | 193 | ```sh 194 | oc get machines -n openshift-machine-api 195 | ``` 196 | 197 | You will see something like: 198 | 199 | ``` 200 | NAME INSTANCE STATE TYPE REGION ZONE AGE 201 | beta-190305-1-79tf5-master-0 i-080dea906d9750737 running m4.xlarge us-east-1 us-east-1a 26h 202 | beta-190305-1-79tf5-master-1 i-0bf5ad242be0e2ea1 running m4.xlarge us-east-1 us-east-1b 26h 203 | beta-190305-1-79tf5-master-2 i-00f13148743c13144 running m4.xlarge us-east-1 us-east-1c 26h 204 | beta-190305-1-79tf5-worker-us-east-1a-8dvwq i-06ea8662cf76c7591 running m4.large us-east-1 us-east-1a 2m7s 205 | beta-190305-1-79tf5-worker-us-east-1a-9pzvg i-0bf01b89256e7f39f running m4.large us-east-1 us-east-1a 2m7s 206 | beta-190305-1-79tf5-worker-us-east-1a-vvddp i-0e649089d42751521 running m4.large us-east-1 us-east-1a 2m7s 207 | beta-190305-1-79tf5-worker-us-east-1a-xx282 i-07b2111dff3c7bbdb running m4.large us-east-1 us-east-1a 26h 208 | beta-190305-1-79tf5-worker-us-east-1b-hjv9c i-0562517168aadffe7 running m4.large us-east-1 us-east-1b 26h 209 | beta-190305-1-79tf5-worker-us-east-1c-cdhth i-09fbcd1c536f2a218 running m4.large us-east-1 us-east-1c 26h 210 | ``` 211 | 212 | You should see a scaled-up cluster with three new additions as worker nodes 213 | in the region where you defined a `MachineAutoScaler`. You can see the ones 214 | that have been auto-scaled from their age. 215 | 216 | Depending on when you run the command, your list may show all running 217 | workers, or some pending. After the `Job` completes, which could take anywhere 218 | from a few minutes to ten or more (depending on your `ClusterAutoscaler` size 219 | and your `MachineAutoScaler` sizes), the cluster should scale down to the 220 | original count of worker nodes. You can watch the output with the following 221 | (runs every 10s)- 222 | 223 | ```sh 224 | watch -n10 'oc get machines -n openshift-machine-api' 225 | ``` 226 | 227 | Press Ctrl-C to break out of the watch. 228 | 229 | In Grafana, be sure to click the `autoscale-example` project in the graphs, 230 | otherwise the interesting things happening might get drowned out by the rest 231 | of the baseline. 232 | 233 | # Infrastructure Nodes 234 | Continue on to the section that details [infrastructure nodes](05-infrastructure-nodes.md). 235 | -------------------------------------------------------------------------------- /docs/05-infrastructure-nodes.md: -------------------------------------------------------------------------------- 1 | # OpenShift Infrastructure Nodes 2 | The OpenShift subscription model allows customers to run various core 3 | infrastructure components at no additional charge. In other words, a node 4 | that is only running core OpenShift infrastructure components is not counted 5 | in terms of the total number of subscriptions required to cover the 6 | environment. 7 | 8 | OpenShift components that fall into the infrastructure categorization 9 | include: 10 | 11 | * kubernetes and OpenShift control plane services ("masters") 12 | * router 13 | * container image registry 14 | * cluster metrics collection ("monitoring") 15 | * cluster aggregated logging 16 | * service brokers 17 | 18 | Any node running a container/pod/component not described above is considered 19 | a worker and must be covered by a subscription. 20 | 21 | ## Infrastructure MachineSets 22 | The documentation covers [creating infrastructure 23 | machinesets](https://docs.openshift.com/container-platform/4.0/machine_management/creating-infrastructure-machinesets.html). 24 | It also goes into detail on moving various OpenShift infrastructure 25 | components. Take a look at all of the documentation and then come back here 26 | to look at the various notes and suggestions before you try anything. 27 | 28 | ## Docs Notes and Omissions 29 | 30 | ### Automagic 31 | 32 | The following scriptlet assumes you have an AWS region called `us-east-1e` 33 | and will build and create an infra `MachineSet` for you with 3 replicas. It 34 | requires the `jq` program be installed. 35 | 36 | ```bash 37 | export REGION=us-east-1e 38 | export NAME="infra-$REGION" 39 | oc get machineset -n openshift-machine-api -o json\ 40 | | jq '.items[0]'\ 41 | | jq '.metadata.name=env["NAME"]'\ 42 | | jq '.spec.selector.matchLabels."machine.openshift.io/cluster-api-machineset"=env["NAME"]'\ 43 | | jq '.spec.template.metadata.labels."machine.openshift.io/cluster-api-machineset"=env["NAME"]'\ 44 | | jq '.spec.template.spec.metadata.labels."node-role.kubernetes.io/infra"=""'\ 45 | | jq 'del (.metadata.annotations)'\ 46 | | jq '.spec.replicas=3'\ 47 | | oc create -f - 48 | ``` 49 | 50 | ### Add More Machinesets (or scale, or both) 51 | In a realistic production deployment, you would want at least 3 `MachineSets` 52 | to hold infrastructure components. Both the logging aggregation solution and 53 | the service mesh will deploy ElasticSearch, and ElasticSearch really needs 3 54 | instances spread across 3 discrete nodes. Why 3 `MachineSets`? Well, in 55 | theory, having a `MachineSet` in different AZs ensures that you don't go 56 | completely dark if AWS loses an AZ. 57 | 58 | For testing purposes, you could just scale a single infra `MachineSet` to 3 59 | replicas. 60 | 61 | If you do want to create multiple `MachineSets` you can simply modify the 62 | scriptlet above for whichever regions you want. 63 | 64 | ### Extra Credit 65 | In the `openshift-machine-api` project are several `Pods`. One of them has a 66 | name of ` clusterapi-manager-controllers-....`. If you use `oc logs` on the 67 | various containers in that `Pod`, you will see the various operator bits that 68 | actually make the nodes come into existence. 69 | 70 | ### Router moving not working 71 | The actual moving of the pod is currently not working. You can track the 72 | progress here: 73 | 74 | https://bugzilla.redhat.com/show_bug.cgi?id=1683761 75 | https://bugzilla.redhat.com/show_bug.cgi?id=1683762 76 | https://bugzilla.redhat.com/show_bug.cgi?id=1683763 77 | 78 | ### Monitoring 79 | The docs incorrectly say that the Monitoring solution cannot be modified. 80 | This is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1688487 81 | 82 | The Cluster Monitoring operator is responsible for deploying and managing the 83 | state of the Prometheus+Grafana+AlertManager cluster monitoring stack. It is 84 | installed by default during the initial cluster installation. Its operator 85 | uses a `ConfigMap` in the `openshift-monitoring` project to set various 86 | tunables and settings for the behavior of the monitoring stack. 87 | 88 | Take a look at the following file: 89 | 90 | https://github.com/openshift/training/blob/master/assets/cluster-monitoring-configmap.yaml 91 | 92 | It contains the definition for a `ConfigMap` that will cause the monitoring 93 | solution to be redeployed onto infrastructure nodes. There is no `ConfigMap` 94 | created as part of the installation. Without one, the operator will assume 95 | default settings: 96 | 97 | ```sh 98 | oc get configmap cluster-monitoring-config -n openshift-monitoring 99 | ``` 100 | 101 | The operator will, in turn, create several `ConfigMap` objects for the 102 | various monitoring stack components, and you can see them, too: 103 | 104 | ```sh 105 | oc get configmap -n openshift-monitoring 106 | ``` 107 | 108 | You can create the new monitoring config with the following command: 109 | 110 | ```sh 111 | oc create -f https://raw.githubusercontent.com/openshift/training/master/assets/cluster-monitoring-configmap.yaml 112 | ``` 113 | 114 | Then, you can do something like `watch 'oc get pod -n openshift-monitoring'` 115 | or `oc get pod -w -n openshift-monitoring` to watch the operator cause the 116 | various pods to be redeployed. 117 | 118 | ## Logging 119 | Logging is handled in its own document, [installing and configuring log 120 | aggregation](08-logging.md). The installation and configuration of logging 121 | uses the Operator Lifecycle Manager, so you may want to go through the 122 | section on [extensions to your cluster](07-extensions.md) first. 123 | 124 | ## Configuring Authentication 125 | The [configuring authentication](06-authentication.md) section describes how 126 | to configure htpasswd-based auth for your cluster. 127 | -------------------------------------------------------------------------------- /docs/06-authentication.md: -------------------------------------------------------------------------------- 1 | # Configuring Authentication 2 | OpenShift 4 installs with two effective superusers: 3 | 4 | * `kubeadmin` (technically an alias for `kube:admin`) 5 | * `system:admin` 6 | 7 | Why two? Because `system:admin` is a user that uses a certificate to login 8 | and has no password. Therefore this superuser cannot log-in to the web 9 | console (which requires a password). 10 | 11 | If you want additional users to be able to authenticate to and use the 12 | cluster, you must configure an authentication provider. The documentation 13 | provides some [background on authentication in 14 | OpenShift](https://docs.openshift.com/container-platform/4.0/authentication/understanding-authentication.html). 15 | 16 | # htpasswd Authentication 17 | The documentation covers [configuring htpasswd as an identity 18 | provider](https://docs.openshift.com/container-platform/4.0/authentication/identity_providers/configuring-htpasswd-identity-provider.html). 19 | 20 | ## The htpasswd File 21 | You can create an `htpasswd` file in whatever way suits you. You can use the 22 | `htpasswd` utility provided by `httpd-tools`, or you can do something like: 23 | 24 | ```sh 25 | printf "USER:$(openssl passwd -apr1 PASSWORD)\n >> /path/to/htpasswd" 26 | ``` 27 | 28 | or any number of other mechanisms. If you don't want to create a file, you 29 | can use the following sample file: 30 | 31 | https://github.com/openshift/training/blob/master/assets/htpasswd 32 | 33 | Note that all users have the password `openshift4`. 34 | 35 | Make sure you know what your file is called. We use a file called `htpasswd` 36 | in the rest of the examples. 37 | 38 | ## The CustomResource 39 | You might be wondering why `apply` was used here. It is because there is an 40 | existing `OAuth` called `cluster`. The CRD that defines `OAuth` is 41 | `oauths.config.openshift.io`. It is a cluster-scoped object. The `apply` 42 | command will overwrite existing objects. 43 | 44 | ## Test Authentication 45 | When you created the CR, the authentication operator reconfigured the cluster 46 | to use htpasswd authentication. After a few moments, you should be able to 47 | `oc login` as one of the users you created. If you used our example file, we 48 | have a user called `susan`: 49 | 50 | ```sh 51 | oc login -u susan -p openshift4 52 | ``` 53 | 54 | You should see something like the following: 55 | 56 | ``` 57 | Login successful. 58 | 59 | You don't have any projects. You can try to create a new project, by running 60 | 61 | oc new-project 62 | ``` 63 | 64 | # Extensions with Operators 65 | You can extend your cluster to do many more exciting things using Operators. 66 | Take a look at the [extensions](07-extensions.md) section for an example of 67 | using Couchbase. 68 | -------------------------------------------------------------------------------- /docs/07-extensions.md: -------------------------------------------------------------------------------- 1 | # Extensions to OpenShift using OperatorHub 2 | 3 | The documentation provides a lot of information on [what operators 4 | are](https://docs.openshift.com/container-platform/4.0/applications/operators/olm-what-operators-are.html) 5 | as well as details on the OperatorHub and [how to add operators to the 6 | cluster](https://docs.openshift.com/container-platform/4.0/applications/operators/olm-what-operators-are.html). 7 | 8 | The documentation provides an example of how to both install the `etcd` 9 | Operator as well as how to [create an application from an installed 10 | operator](https://docs.openshift.com/container-platform/4.0/applications/operators/olm-creating-apps-from-installed-operators.html). 11 | 12 | The example below describes how to do the same with Couchbase. Couchbase is a 13 | powerful NoSQL database. 14 | 15 | ## Create a Project 16 | Before you get started, create a project for what you're about to do with 17 | Couchbase. You can either do it from the command line: 18 | 19 | ```sh 20 | oc new-project mycouchbase 21 | ``` 22 | 23 | or create it from the web console. 24 | 25 | ## Installing an Extension 26 | 27 | Open the OpenShift web console, click to "Catalog", then "OperatorHub". At 28 | the top of the page, in the Project selector, choose `mycouchbase`. 29 | 30 | Search or browse to the Couchbase Operator and click it. The description lays 31 | out the notable features of the Operator. Go ahead and click "Install" to 32 | deploy the Operator on to the cluster. It may take several moments after 33 | clicking "Install" before the Subscription page shows up. 34 | 35 | ### Installation Mode 36 | 37 | Operators can be enabled for all Projects across the cluster or only within 38 | specific namespaces. Not all Operators support each of these installation 39 | methods. The Couchbase operator only supports installation for a specific 40 | namespace. Make sure `mycouchbase` is selected to match the project you 41 | created earlier. 42 | 43 | ### Update Channel 44 | 45 | Each Operator publisher can create channels for their software, to give 46 | administrators more control over the versions that are installed. In this 47 | case, Couchbase only has a "preview" channel. 48 | 49 | ### Update Approval Strategy 50 | 51 | If Operator creators enable their operators to update the deployed solutions, 52 | Operator Lifecycle Manager is able to automatically apply those updates. 53 | Cluster administrators can decide whether or not OLM should or should not 54 | automatically apply updates. In the future, when Couchbase releases an 55 | updated operator to the "preview" channel, you can decide whether you want to 56 | approve each update, or have it happen automatically. Choose "Automatic" for 57 | now. 58 | 59 | After clicking "Subscribe", the Couchbase entry will now show that it is 60 | "Installed". 61 | 62 | **Note:** While the Operator Hub page indicates that the operator is 63 | "installed", really it is indicating that the Operator is configured to be 64 | installed. It may take several minutes for OpenShift to pull in the Operator 65 | to the cluster. You can check on the status of this operator with the 66 | following command: 67 | 68 | ```sh 69 | oc get pod -all-namespaces | grep couch 70 | ``` 71 | 72 | You will likely see the Couchbase operator pod in `ContainerCreating` status 73 | if you look very soon after finishing the installation/subscription process. 74 | 75 | ## Using Secrets 76 | The Couchbase operator is capable of installing and managing a Couchbase 77 | cluster for you. But, before it can do that, it has a [prerequisite for a 78 | Kubernetes 79 | secret](https://docs.couchbase.com/operator/1.1/couchbase-cluster-config.html#authsecret) 80 | that it can use to configure the username and password for the cluster. You 81 | have a few ways to create this secret. 82 | 83 | 1. You can create a key/value secret with a `username` and `password` key in 84 | the OpenShift web console by navigating to "Workloads" and then "Secrets". 85 | Make sure the Project selector is set to `mycouchbase`. Finally, you can 86 | click "Create" and choose "Key/Value Secret". 87 | 88 | 1. You can make sure the Project selector is set to `mycouchbase` and then 89 | click "+ Add" at the upper right-hand area of the web console, and then 90 | choose "Import YAML". Paste the following YAML into the form (the username is 91 | "couchbase" and the password is "securepassword"): 92 | 93 | ```YAML 94 | apiVersion: v1 95 | data: 96 | password: c2VjdXJlcGFzc3dvcmQ= 97 | username: Y291Y2hiYXNl 98 | kind: Secret 99 | metadata: 100 | name: cb-example-auth 101 | namespace: mycouchbase 102 | type: Opaque 103 | ``` 104 | 105 | 1. You can create the secret directly using the following command: 106 | 107 | ```sh 108 | oc create -f https://raw.githubusercontent.com/openshift/training/master/assets/cb-example-auth.yaml 109 | ``` 110 | 111 | Ultimately, you want a secret with the username `couchbase` and the password 112 | `securepassword` (both example #2/#3 above use that). 113 | 114 | ## Using an Installed Operator 115 | 116 | Regular users will use the "Developer Catalog" menu to add shared apps, 117 | services, or source-to-image builders to projects. Navigate to the "Developer 118 | Catalog" and, at the top of the page, again make sure you select 119 | `mycouchbase` from the Project dropdown. You should see that the Couchbase 120 | operator is available. If you choose a different Project, you should also 121 | notice that the Couchbase operator is **not** available in other Projects. 122 | 123 | Click on the Couchbase Cluster tile, which is a capability that the Operator 124 | has extended our OpenShift cluster to support. Operators can expose more than 125 | one capability. For example, the MongoDB Operator exposes three common 126 | configurations of its database (and you would see three _different_ MongoDB 127 | tiles). 128 | 129 | Deploy an instance of Couchbase by clicking the "Create" button in the top 130 | left. The YAML editor has been pre-filled with a set of defaults for the 131 | resulting Couchbase cluster. One of those defaults is a reference to the 132 | Secret you created earlier. 133 | 134 | ### Changing Couchbase Parameters 135 | 136 | The Couchbase Operator sets up a highly available cluster for us. Your YAML 137 | should look like the following: 138 | 139 | ```YAML 140 | apiVersion: couchbase.com/v1 141 | kind: CouchbaseCluster 142 | metadata: 143 | name: cb-example 144 | namespace: mycouchbase 145 | spec: 146 | authSecret: cb-example-auth 147 | baseImage: registry.connect.redhat.com/couchbase/server 148 | buckets: 149 | - conflictResolution: seqno 150 | enableFlush: true 151 | evictionPolicy: fullEviction 152 | ioPriority: high 153 | memoryQuota: 128 154 | name: default 155 | replicas: 1 156 | type: couchbase 157 | cluster: 158 | analyticsServiceMemoryQuota: 1024 159 | autoFailoverMaxCount: 3 160 | autoFailoverOnDataDiskIssues: true 161 | autoFailoverOnDataDiskIssuesTimePeriod: 120 162 | autoFailoverServerGroup: false 163 | autoFailoverTimeout: 120 164 | clusterName: cb-example 165 | dataServiceMemoryQuota: 256 166 | eventingServiceMemoryQuota: 256 167 | indexServiceMemoryQuota: 256 168 | indexStorageSetting: memory_optimized 169 | searchServiceMemoryQuota: 256 170 | servers: 171 | - name: all_services 172 | services: 173 | - data 174 | - index 175 | - query 176 | - search 177 | - eventing 178 | - analytics 179 | size: 3 180 | version: 5.5.3-3 181 | ``` 182 | 183 | The operator provides many sensible defaults. Take note of the `servers` 184 | stanza and its `size` element. This represents the number of distinct 185 | Couchbase Pods that will be created and managed by the operator. We'll 186 | explore changing that in a moment. 187 | 188 | Click "Create". Afterwards, you will be taken to a list of all Couchbase 189 | instances running with this Project and should see the one you just created 190 | has a status of "Creating". 191 | 192 | ### View the Deployed Resources 193 | 194 | Navigate to the Couchbase Cluster that was deployed by clicking `cb-example`, 195 | and then click on the "Resources" tab. This collects all of the objects 196 | deployed and managed by the Operator. From here you can ultimately view Pod 197 | logs to check on the Couchbase Cluster instances. 198 | 199 | If for some reason you had navigated away from the page after creating your 200 | Couchbase cluster, you can get back here by clicking "Catalog" -> "Installed 201 | Operators" -> "Couchbase Cluster" -> `cb-example`. 202 | 203 | We are going to use the Service `cb-example` to access the Couchbase 204 | dashboard via a Route: 205 | 206 | ```sh 207 | oc expose service cb-example -n mycouchbase 208 | ``` 209 | 210 | You should now have a route: 211 | 212 | ```sh 213 | oc get route -n mycouchbase 214 | ``` 215 | 216 | Which will show something like: 217 | 218 | ``` 219 | NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD 220 | cb-example cb-example-mycouchbase.apps.beta-190304-2.ocp4testing.openshiftdemos.com cb-example couchbase None 221 | ``` 222 | 223 | Your Couchbase installation is now exposed directly to the internet and is 224 | not using HTTPS. Go ahead and copy/paste the URL into your browser. Login 225 | with the user `couchbase` and the password `securepassword` (these were in 226 | your secret). If you used different credentials, make sure you put in the 227 | right ones. 228 | 229 | ### Re-Configure the Cluster with the Operator 230 | 231 | Keep the Couchbase dashboard up as we re-configure the cluster. As the Operator scales 232 | up more Pods, they will automatically join and appear in the dashboard. 233 | 234 | Edit your `cb-example` Couchbase instance to have a server size of `4` 235 | instead of `3`. You can navigate back to the installed instances of Couchbase 236 | via the web console, or you can use: 237 | 238 | ```sh 239 | oc edit couchbaseclusters.couchbase.com/cb-example -n mycouchbase 240 | ``` 241 | 242 | A few things will happen: 243 | 244 | * The Operator will detect the difference between the desired state and the 245 | current state 246 | * A new Pod will be created and show up under "Resources" 247 | * The Couchbase dashboard will show 4 instances once the Pod is created 248 | * The Couchbase dashboard will show that the cluster is being rebalanced 249 | 250 | After the cluster is scaled up to `4`, try scaling back down to `3`. If you 251 | watch the dashboard closely, you will see that Couchbase as automatically 252 | triggered a re-balance of the data within the cluster to reflect the new 253 | topology of the cluster. This is one of many advanced feautres embedded 254 | within applications in OperatorHub to save you time when administering your 255 | workloads. 256 | 257 | ### Delete the Couchbase Instance 258 | 259 | After you are done, delete the `cb-example` Couchbase instance and the 260 | Opeator will clean up all of the resources that were deployed. Remember to 261 | delete the Route that we manually created as well. Remember to delete the 262 | Operator instance and not to delete the Pods or other resources directly -- 263 | the operator will immediately try to fix that thinking that there's a 264 | problem! 265 | 266 | After you delete the `cb-example` instance, if you look at the Project 267 | quickly you'll see the Pods terminating: 268 | 269 | ```sh 270 | oc get pod -n mycouchbase 271 | ``` 272 | 273 | But you'll also see that the Operator Pod remains. That's because there's 274 | still a Subscription for the Couchbase operator in this Project. You can 275 | delete the Subscription (and, thus, the Pod) by going to "Operator 276 | Management" -> "Operator Subscriptions". There you can click the 3 dots and 277 | remove the Subscription for the Couchbase Operator in the `mycouchbase` 278 | Project. Now there should be no Pods, and you can also delete the Project if 279 | you want. 280 | 281 | ## Try Out More Operators 282 | 283 | Operators are a powerful way for cluster administrators to extend the 284 | cluster, so that developers can build their apps and services in a 285 | self-service way. With the expertise baked into an Operator, running high 286 | quality, production instructure has never been easier. 287 | 288 | OperatorHub will be continually updated with more great Operators from Red 289 | Hat, certified partners and the Kubernetes community. 290 | 291 | # End of Materials 292 | Congratulations. You have reached the end of the materials. Feel free to 293 | explore your cluster further. 294 | 295 | If you are done, you can proceed to [cleanup your cluster](98-cleanup.md) You 296 | can also take a look at the [tips and tricks](97-tips-and-tricks.md) section. -------------------------------------------------------------------------------- /docs/08-logging.md: -------------------------------------------------------------------------------- 1 | # Log Aggregation in OpenShift 2 | The log aggregation solution in OpenShift 4 is not changed from the 3 | ElasticSearch, Kibana and FluentD stack. The installation process, though, 4 | has changed. 5 | 6 | Take a moment to familiarize yourself with the [logging 7 | overview](https://docs.openshift.com/container-platform/4.0/logging/efk-logging.html). 8 | 9 | # Deploying Logging 10 | Deploying the logging solution requires only a few steps. Take a look at the 11 | [deploying cluster 12 | logging](https://docs.openshift.com/container-platform/4.0/logging/efk-logging-deploy.html#efk-logging-deploy-subscription-efk-logging-deploy) 13 | documentation. There are some additional notes on the process here. 14 | 15 | ## Create the Logging Project 16 | You can create the required Project with the following command: 17 | 18 | ```sh 19 | oc create -f https://raw.githubusercontent.com/openshift/training/master/assets/logging-project.yaml 20 | ``` 21 | 22 | This YAML already has the annotations and appropriate details. 23 | 24 | ## Logging CR 25 | If you had followed the instructions for [creating infrastructure 26 | nodes](docs/05-infrastructure-nodes.md), you already have some special nodes 27 | with special labels. When you get to the section on "Create a cluster logging 28 | instance", if you want to deploy the logging solution onto your 29 | infrastructure nodes, we have an existing CR that you can use. 30 | 31 | https://raw.githubusercontent.com/openshift/training/master/assets/logging-cr.yaml 32 | 33 | You can paste the contents of the CR into the web console. 34 | 35 | ## Set Default Index Pattern 36 | When the Logging solution is finished installing, find the route for Kibana, 37 | click through to it, accept all certificates and login as `kubeadmin`. You 38 | will find that Kibana wants you to set a default index pattern. 39 | 40 | Click `.all` on the left and then click the star icon on the right to set 41 | this as the default index. You will notice that a star icon appears on the 42 | left next to `.all`. At this point you can click "Discover" to perform your 43 | searches. -------------------------------------------------------------------------------- /docs/09-istio.md: -------------------------------------------------------------------------------- 1 | # Istio Service Mesh 2 | While Istio is still in Tech Preview state, it is installable on top of OCP4 3 | with some small caveats. 4 | 5 | ## Installing Istio 6 | Take a look at the [OpenShift 3-based Istio Installation 7 | Overview](https://docs.openshift.com/container-platform/3.11/servicemesh-install/servicemesh-install.html) 8 | documentation. 9 | 10 | ### Skip Node Configuration 11 | Do not perform the [node 12 | configuration](https://docs.openshift.com/container-platform/3.11/servicemesh-install/servicemesh-install.html#updating-node-configuration) 13 | steps. There is a tuned Operator running in OpenShift 4 that will take care 14 | of this for you. 15 | 16 | ### Build Your Istio Configuration CR 17 | The [custom resource 18 | parameters](https://docs.openshift.com/container-platform/3.11/servicemesh-install/servicemesh-install.html#custom-resource-parameters) 19 | documentation describes the various options you can put into the CR that tell 20 | the Operator how to configure Istio. You can also just use the minimal CR to 21 | start. You can actually find that CR here: 22 | 23 | https://raw.githubusercontent.com/Maistra/openshift-ansible/maistra-0.9/istio/istio-installation-minimal.yaml 24 | 25 | ### Istio Operator 26 | You can follow the [Istio operator 27 | installation](https://docs.openshift.com/container-platform/3.11/servicemesh-install/servicemesh-install.html#installing-operator) 28 | steps as written. 29 | 30 | ### Deploy the Control Plane 31 | If you want to use the minimal CR, you can simply execute the following: 32 | 33 | ``` 34 | oc create -f https://raw.githubusercontent.com/Maistra/openshift-ansible/maistra-0.9/istio/istio-installation-minimal.yaml -n istio-operator 35 | ``` 36 | 37 | Otherwise, use whatever CR you designed. 38 | 39 | ## Application Requirements 40 | The various instructions for using Istio with your applications are found in 41 | the [application 42 | requirements](https://docs.openshift.com/container-platform/3.11/servicemesh-install/servicemesh-install.html#install_chapter_5) 43 | documentation. 44 | 45 | ## Other Examples 46 | There are various tutorials that you can try with Istio [here](http://bit.ly/istio-tutorial). -------------------------------------------------------------------------------- /docs/97-tips-and-tricks.md: -------------------------------------------------------------------------------- 1 | # Tips and tricks 2 | This section explains some tips and tricks to familiarize with OpenShift 4. 3 | 4 | ## Ignition files 5 | The OpenShift Installer generates different assets depending on the target. 6 | The ignition files for the bootstrap, master and worker machines are generated 7 | by `openshift-install create ignition-configs`. 8 | 9 | For more information about the targets, see https://github.com/openshift/installer/blob/master/docs/user/overview.md#targets 10 | 11 | You can use `jq` to read the files easily: 12 | 13 | ``` 14 | $ jq < master.ign 15 | { 16 | "ignition": { 17 | "config": { 18 | "append": [ 19 | ... 20 | "storage": {}, 21 | "systemd": {} 22 | } 23 | ``` 24 | 25 | ## NTP configuration 26 | 27 | RHCOS uses chronyd to synchronize the system time. The default configuration 28 | uses the `*.rhel.pool.ntp.org` servers: 29 | 30 | ``` 31 | $ grep -v -E '^#|^$' /etc/chrony.conf 32 | server 0.rhel.pool.ntp.org iburst 33 | server 1.rhel.pool.ntp.org iburst 34 | server 2.rhel.pool.ntp.org iburst 35 | server 3.rhel.pool.ntp.org iburst 36 | driftfile /var/lib/chrony/drift 37 | makestep 1.0 3 38 | rtcsync 39 | logdir /var/log/chrony 40 | ``` 41 | 42 | As the hosts configuration shouldn't be managed manually, in order to configure 43 | chronyd to use custom servers or a custom setting, it is required to use the 44 | `machine-config-operator` to modify the files used by the masters and workers 45 | by the following procedure: 46 | 47 | * Create the proper file with your custom tweaks and encode it as base64: 48 | 49 | ``` 50 | cat << EOF | base64 51 | server clock.redhat.com iburst 52 | driftfile /var/lib/chrony/drift 53 | makestep 1.0 3 54 | rtcsync 55 | logdir /var/log/chrony 56 | EOF 57 | ``` 58 | 59 | * Create the MachineConfig file with the base64 string from the previous command 60 | as: 61 | 62 | ``` 63 | cat << EOF > ./masters-chrony-configuration.yaml 64 | apiVersion: machineconfiguration.openshift.io/v1 65 | kind: MachineConfig 66 | metadata: 67 | labels: 68 | machineconfiguration.openshift.io/role: master 69 | name: masters-chrony-configuration 70 | spec: 71 | config: 72 | ignition: 73 | config: {} 74 | security: 75 | tls: {} 76 | timeouts: {} 77 | version: 2.2.0 78 | networkd: {} 79 | passwd: {} 80 | storage: 81 | files: 82 | - contents: 83 | source: data:text/plain;charset=utf-8;base64,c2VydmVyIGNsb2NrLnJlZGhhdC5jb20gaWJ1cnN0CmRyaWZ0ZmlsZSAvdmFyL2xpYi9jaHJvbnkvZHJpZnQKbWFrZXN0ZXAgMS4wIDMKcnRjc3luYwpsb2dkaXIgL3Zhci9sb2cvY2hyb255Cg== 84 | verification: {} 85 | filesystem: root 86 | mode: 420 87 | path: /etc/chrony.conf 88 | osImageURL: "" 89 | EOF 90 | ``` 91 | 92 | Substitute the base64 string with your own. 93 | 94 | * Apply it 95 | 96 | ``` 97 | oc apply -f ./masters-chrony-configuration.yaml 98 | ``` 99 | 100 | ## OCP Master configuration 101 | The master configuration is now stored in a `configMap`. During the installation 102 | process, a few `configMaps` are created, so in order to get the latest: 103 | 104 | ``` 105 | oc get cm -n openshift-kube-apiserver | grep config 106 | ``` 107 | 108 | Observe the latest id and then: 109 | 110 | ``` 111 | oc get cm -n openshift-kube-apiserver config-ID 112 | ``` 113 | 114 | To get the output in a human-readable form, use: 115 | 116 | ``` 117 | oc get cm -n openshift-kube-apiserver config-ID \ 118 | -o jsonpath='{.data.config\.yaml}' | jq 119 | ``` 120 | 121 | For the OpenShift api configuration: 122 | 123 | ``` 124 | oc get cm -n openshift-apiserver config -o jsonpath='{.data.config\.yaml}' | jq 125 | ``` 126 | 127 | ## Delete 'Completed' pods 128 | 129 | During the installation process, a few temporary pods are created. Keeping those 130 | pods as 'Completed' doesn't harm nor waste resources but if you want to delete 131 | them to have only 'running' pods in your environment you can use the following 132 | command: 133 | 134 | ``` 135 | oc get pods --all-namespaces | \ 136 | awk '{if ($4 == "Completed") system ("oc delete pod " $2 " -n " $1 )}' 137 | ``` 138 | 139 | ## Get pods not running nor completed 140 | 141 | A handy one liner to see the pods having issues (such as CrashLoopBackOff): 142 | 143 | ``` 144 | oc get pods --all-namespaces | grep -v -E 'Completed|Running' 145 | ``` 146 | -------------------------------------------------------------------------------- /docs/98-cleanup.md: -------------------------------------------------------------------------------- 1 | # Deleting the Cluster and Cleaning up 2 | 3 | Cleaning up your cluster is straightforward *if* you preserved the 4 | `metadata.json` file from cluster creation. It is usually possible to 5 | reconstruct the file if you lose it, but that depends on still having 6 | a functioning cluster or poking around in AWS, so it's better to just 7 | hang on to the file. 8 | 9 | Also, if you added an EC2 instance to your VPC in order to be able to SSH 10 | into the cluster, make sure that you manually delete it first before 11 | attempting to delete your cluster. Our instructions did not provide 12 | sufficient detail to ensure that the installer could "find" the EC2 instance 13 | in order to delete it. Failing to manually delete the EC2 instance you 14 | manually created will result in the deletion of your cluster hanging and 15 | never completing. 16 | 17 | The following command will read `metadata.json` and remove the 18 | OpenShift 4 cluster and all underlying AWS resources that were created 19 | by the installer: 20 | 21 | ./openshift-install destroy cluster 22 | 23 | As with `create`, you can set `--dir` to use an asset directory other 24 | than your current working directory. You should use the same asset 25 | directory for `destroy` that you used for `create`. 26 | -------------------------------------------------------------------------------- /docs/99-troubleshooting.md: -------------------------------------------------------------------------------- 1 | # Troubleshooting 2 | This section helps troubleshoot various issues that you might encounter 3 | during your exploration of OpenShift 4. 4 | 5 | ## Installation 6 | There are a number of problems that commonly occur that we have documented in 7 | the [installer's GitHub 8 | repository](https://github.com/openshift/installer/blob/master/docs/user/troubleshooting.md). 9 | If you don't find your particular issue, as of the time of this writing, you 10 | will need to do a fresh install. 11 | 12 | If you used the `--dir` option when you installed, you already have a 13 | separate folder somewhere that contains the artifacts. If you did **NOT** use 14 | the `--dir` option during the installation, you will want to capture and 15 | retain installer log. 16 | 17 | mv .openshift_install.log openshift_install_fail_logs 18 | 19 | In either case, please try to capture any console output from the installer 20 | to a separate file. 21 | 22 | Then, [clean up your cluster](98-cleanup.md). 23 | 24 | Finally, re-start the install process 25 | 26 | ./openshift-install create cluster 27 | 28 | -------------------------------------------------------------------------------- /img/all-systems.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openshift/training/5a90c2424d37f956f7890455be17d8b760e36848/img/all-systems.png -------------------------------------------------------------------------------- /img/grafana.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openshift/training/5a90c2424d37f956f7890455be17d8b760e36848/img/grafana.png -------------------------------------------------------------------------------- /img/machine-set.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openshift/training/5a90c2424d37f956f7890455be17d8b760e36848/img/machine-set.png -------------------------------------------------------------------------------- /img/scale-nodes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openshift/training/5a90c2424d37f956f7890455be17d8b760e36848/img/scale-nodes.png --------------------------------------------------------------------------------