DISCLAIMER: THE ALL-IN-ONE (AIO) OCP DEPLOYMENT IS A COMMERCIALLY UNSUPPORTED OCP CONFIGURATION INTENDED FOR TESTING OR DEMO PURPOSES.
Back in the 3.x days, I documented the All-in-One (AIO) deployment of OCP 3.11 for lab environments and other possible use cases. That blog post is available here: https://blog.openshift.com/openshift-all-in-one-aio-for-labs-and-fun/
With OCP4.2 (and OCP4.3 nightly builds) the all-in-one (AIO) deployment is also possible. Before going into the details I should highlight that this particular setup does have the same DNS requirements and prerequisites as any other OCP 4.x deployment.
This approach is NOT the best option for a local development environment on a laptop. This AIO is for external deployments in a home lab or cloud-based lab. If looking for an OCP 4.x development environment to run in a laptop, I highly recommend using RedHat CodeReady Containers which is a maintained solution for that specific purpose https://developers.redhat.com/products/codeready-containers
Back to the all-in-one deployment. There are two approaches to achieve the OCP4.2 all-in-one configuration:
Option 1: Customizing the manifests before installation
During the installation process generate the manifests them with “openshift-install create manifests –dir ./aio”. Then proceed to update the resulting ingress manifest in “./aio/manifests” and inject replacement manifests for the CVO, etcd-quorum-guard. After this, then generate the ignition files for the installation.
This is highly customizable and can be set so it does not require any post-install configuration. This method requires advanced OpenShift skills and it is NOT covered in this blog post.
Option 2: Customize the cluster during and after deployment
After the “bootkube.service” bootstrap process completes, update CVO to disable management of the etcd-quorum-guard Deployment and scale to one the etcd-quorum-guard and ingress controller. This is the approach covered in this blog.
The Design
NOTE: This document assumes the reader is familiar with the OCP4x installation process.
The final deployment will have cluster admins, developers, application owners (see #1), automation tools (see #2) and users of the applications (see #3) going to the same IP but different ports or routes. The logical view is as shown in the following diagram:
The host characteristics that I tested for this configuration:
VM or bare-metal
8 vCPU
16GB RAM
20GB Disk
Before Deployment
Setup the install-config.yaml to deploy a single master and no workers
apiVersion: v1
baseDomain: example.com
compute:
– hyperthreading: Enabled
name: worker
replicas: 0
controlPlane:
hyperthreading: Enabled
name: master
replicas: 1
metadata:
name: aio
networking:
clusterNetworks:
– cidr: 10.128.0.0/14
hostPrefix: 23
networkType: OpenShiftSDN
serviceNetwork:
– 172.30.0.0/16
platform:
none: {}
pullSecret: ”
sshKey: ‘ssh-rsa AAA…’
During Deployment
During installation there still need for a temporary external load balancer (or poor man version, modify the DNS entries).
For the installation prepare the DNS equivalent to this:
aio.example.com
etcd-0.aio.example.com
apps.aio.example.com
*.apps.aio.example.com
api-int.aio.example.com
api.aio.example.com
# etcd Service Record
_etcd-server-ssl._tcp.aio.example.com. IN SRV 0 0 2380 etcd-0.aio.example.com.
After bootkube.service completes modify the DNS
aio.example.com
etcd-0.aio.example.com
apps.aio.example.com
*.apps.aio.example.com
api-int.aio.example.com
api.aio.example.com
# etcd Service Record
_etcd-server-ssl._tcp.aio.example.com. IN SRV 0 0 2380 etcd-0.aio.example.com.
The single node will be shown with both roles (master and worker)
$ oc get nodes
NAME STATUS ROLES AGE VERSION
aio Ready master,worker 33m v1.16.2
Set etcd-quorum-guard to unmanaged state
oc patch clusterversion/version –type=’merge’ -p “$(cat <<- EOF
spec:
overrides:
– group: apps/v1
kind: Deployment
name: etcd-quorum-guard
namespace: openshift-machine-config-operator
unmanaged: true
EOF
)”
Downscale etcd-quorum-guard to one:
oc scale –replicas=1 deployment/etcd-quorum-guard -n openshift-machine-config-operator
Downscale the number of routers to one:
oc scale –replicas=1 ingresscontroller/default -n openshift-ingress-operator
(Recommended) Downscale the number of consoles, authentication, OLM and monitoring services to one:
oc scale –replicas=1 deployment.apps/console -n openshift-console
oc scale –replicas=1 deployment.apps/downloads -n openshift-console
oc scale –replicas=1 deployment.apps/oauth-openshift -n openshift-authentication
oc scale –replicas=1 deployment.apps/packageserver -n openshift-operator-lifecycle-manager
# NOTE: When enabled, the Operator will auto-scale this services back to original quantity
oc scale –replicas=1 deployment.apps/prometheus-adapter -n openshift-monitoring
oc scale –replicas=1 deployment.apps/thanos-querier -n openshift-monitoring
oc scale –replicas=1 statefulset.apps/prometheus-k8s -n openshift-monitoring
oc scale –replicas=1 statefulset.apps/alertmanager-main -n openshift-monitoring
(optional) Setup image-registry to use ephemeral storage.
WARNING: Only use ephemeral storage for internal registry for testing purposes.
oc patch configs.imageregistry.operator.openshift.io cluster –type merge
–patch ‘{“spec”:{“storage”:{“emptyDir”:{}}}}’
oc patch configs.imageregistry.operator.openshift.io cluster –type merge
–patch ‘{“spec”:{“managementState”:”Managed”}}’
NOTE: Wait until the image-registry operator completes the update before using the registry.
The post Revamped OpenShift All-in-One (AIO) for Labs and Fun appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift
Published by