Este contenido no está disponible en el idioma seleccionado.
Chapter 3. Deploying OpenShift sandboxed containers on AWS
You can deploy OpenShift sandboxed containers on AWS Cloud Computing Services by using the OpenShift Container Platform web console or the command line interface (CLI).
OpenShift sandboxed containers deploys peer pods. The peer pod design circumvents the need for nested virtualization. For more information, see peer pod and Peer pods technical deep dive.
Cluster requirements
- You have installed Red Hat OpenShift Container Platform 4.14 or later on the cluster where you are installing the OpenShift sandboxed containers Operator.
- Your cluster has at least one worker node.
For details on installing OpenShift Container Platform on AWS Cloud Computing Services see Installing on AWS.
3.1. Peer pod resource requirements Copiar enlaceEnlace copiado en el portapapeles!
You must ensure that your cluster has sufficient resources.
Peer pod virtual machines (VMs) require resources in two locations:
-
The worker node. The worker node stores metadata, Kata shim resources (
containerd-shim-kata-v2), remote-hypervisor resources (cloud-api-adaptor), and the tunnel setup between the worker nodes and the peer pod VM. - The cloud instance. This is the actual peer pod VM running in the cloud.
The CPU and memory resources used in the Kubernetes worker node are handled by the pod overhead included in the RuntimeClass (kata-remote) definition used for creating peer pods.
The total number of peer pod VMs running in the cloud is defined as Kubernetes Node extended resources. This limit is per node and is set by the PEERPODS_LIMIT_PER_NODE attribute in the peer-pods-cm config map.
The extended resource is named kata.peerpods.io/vm, and enables the Kubernetes scheduler to handle capacity tracking and accounting.
You can edit the limit per node based on the requirements for your environment after you install the OpenShift sandboxed containers Operator.
A mutating webhook adds the extended resource kata.peerpods.io/vm to the pod specification. It also removes any resource-specific entries from the pod specification, if present. This enables the Kubernetes scheduler to account for these extended resources, ensuring the peer pod is only scheduled when resources are available.
The mutating webhook modifies a Kubernetes pod as follows:
-
The mutating webhook checks the pod for the expected
RuntimeClassNamevalue, specified in theTARGET_RUNTIME_CLASSenvironment variable. If the value in the pod specification does not match the value in theTARGET_RUNTIME_CLASS, the webhook exits without modifying the pod. If the
RuntimeClassNamevalues match, the webhook makes the following changes to the pod spec:-
The webhook removes every resource specification from the
resourcesfield of all containers and init containers in the pod. -
The webhook adds the extended resource (
kata.peerpods.io/vm) to the spec by modifying the resources field of the first container in the pod. The extended resourcekata.peerpods.io/vmis used by the Kubernetes scheduler for accounting purposes.
-
The webhook removes every resource specification from the
The mutating webhook excludes specific system namespaces in OpenShift Container Platform from mutation. If a peer pod is created in those system namespaces, then resource accounting using Kubernetes extended resources does not work unless the pod spec includes the extended resource.
As a best practice, define a cluster-wide policy to only allow peer pod creation in specific namespaces.
3.2. Deploying OpenShift sandboxed containers by using the web console Copiar enlaceEnlace copiado en el portapapeles!
You can deploy OpenShift sandboxed containers on AWS by using the OpenShift Container Platform web console to perform the following tasks:
- Install the OpenShift sandboxed containers Operator.
- Optional: Enable ports 15150 and 9000 to allow internal communication with peer pods.
- Optional: Create the peer pods secret if you uninstalled the Cloud Credential Operator, which is installed with the OpenShift sandboxed containers Operator.
- Optional: Select a custom pod VM image.
- Optional: Customize the Kata agent policy.
- Create the peer pods config map.
-
Create the
KataConfigcustom resource. - Configure the OpenShift sandboxed containers workload objects.
3.2.1. Installing the OpenShift sandboxed containers Operator Copiar enlaceEnlace copiado en el portapapeles!
You can install the OpenShift sandboxed containers Operator by using the OpenShift Container Platform web console.
Prerequisites
-
You have access to the cluster as a user with the
cluster-adminrole.
Procedure
-
In the web console, navigate to Operators
OperatorHub. -
In the Filter by keyword field, type
OpenShift sandboxed containers. - Select the OpenShift sandboxed containers Operator tile and click Install.
- On the Install Operator page, select stable from the list of available Update Channel options.
Verify that Operator recommended Namespace is selected for Installed Namespace. This installs the Operator in the mandatory
openshift-sandboxed-containers-operatornamespace. If this namespace does not yet exist, it is automatically created.NoteAttempting to install the OpenShift sandboxed containers Operator in a namespace other than
openshift-sandboxed-containers-operatorcauses the installation to fail.- Verify that Automatic is selected for Approval Strategy. Automatic is the default value, and enables automatic updates to OpenShift sandboxed containers when a new z-stream release is available.
- Click Install.
-
Navigate to Operators
Installed Operators to verify that the Operator is installed.
3.2.2. Enabling ports for AWS Copiar enlaceEnlace copiado en el portapapeles!
You must enable ports 15150 and 9000 to allow internal communication with peer pods running on AWS.
Prerequisites
- You have installed the OpenShift sandboxed containers Operator.
- You have installed the AWS command line tool.
-
You have access to the cluster as a user with the
cluster-adminrole.
Procedure
Log in to your OpenShift Container Platform cluster and retrieve the instance ID:
INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' \ -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' \ -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')Copy to Clipboard Copied! Toggle word wrap Toggle overflow Retrieve the AWS region:
AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}')$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow Retrieve the security group IDs and store them in an array:
AWS_SG_IDS=($(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \ --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \ --output text --region $AWS_REGION))$ AWS_SG_IDS=($(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \ --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \ --output text --region $AWS_REGION))Copy to Clipboard Copied! Toggle word wrap Toggle overflow For each security group ID, authorize the peer pods shim to access kata-agent communication, and set up the peer pods tunnel:
for AWS_SG_ID in "${AWS_SG_IDS[@]}"; do \ aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 15150 --source-group $AWS_SG_ID --region $AWS_REGION \ aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 9000 --source-group $AWS_SG_ID --region $AWS_REGION \ done$ for AWS_SG_ID in "${AWS_SG_IDS[@]}"; do \ aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 15150 --source-group $AWS_SG_ID --region $AWS_REGION \ aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 9000 --source-group $AWS_SG_ID --region $AWS_REGION \ doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow
The ports are now enabled.
3.2.3. Creating the peer pods secret Copiar enlaceEnlace copiado en el portapapeles!
When the peer pods secret is empty and the Cloud Credential Operator (CCO) is installed, the OpenShift sandboxed containers Operator uses the CCO to retrieve the secret. If you have uninstalled the CCO, you must create the peer pods secret for OpenShift sandboxed containers manually or the peer pods will fail to operate.
The secret stores credentials for creating the pod virtual machine (VM) image and peer pod instances.
By default, the OpenShift sandboxed containers Operator creates the secret based on the credentials used to create the cluster. However, you can manually create a secret that uses different credentials.
Prerequisites
You have the following values generated by using the AWS console:
-
AWS_ACCESS_KEY_ID -
AWS_SECRET_ACCESS_KEY
-
Procedure
-
In the OpenShift Container Platform web console, navigate to Operators
Installed Operators. - Click the OpenShift sandboxed containers Operator tile.
- Click the Import icon (+) on the top right corner.
In the Import YAML window, paste the following YAML manifest:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click Save to apply the changes.
-
Navigate to Workloads
Secrets to verify the peer pods secret.
3.2.4. Creating the peer pods config map Copiar enlaceEnlace copiado en el portapapeles!
You must create the peer pods config map for OpenShift sandboxed containers.
Prerequisites
- You have your Amazon Machine Image (AMI) ID if you are not using the default AMI ID based on your cluster credentials.
Procedure
Obtain the following values from your AWS instance:
Retrieve and record the instance ID:
INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')Copy to Clipboard Copied! Toggle word wrap Toggle overflow This is used to retrieve other values for the secret object.
Retrieve and record the AWS region:
AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}') && echo "AWS_REGION: \"$AWS_REGION\""$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}') && echo "AWS_REGION: \"$AWS_REGION\""Copy to Clipboard Copied! Toggle word wrap Toggle overflow Retrieve and record the AWS subnet ID:
AWS_SUBNET_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SubnetId' --region ${AWS_REGION} --output text) && echo "AWS_SUBNET_ID: \"$AWS_SUBNET_ID\""$ AWS_SUBNET_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SubnetId' --region ${AWS_REGION} --output text) && echo "AWS_SUBNET_ID: \"$AWS_SUBNET_ID\""Copy to Clipboard Copied! Toggle word wrap Toggle overflow Retrieve and record the AWS VPC ID:
AWS_VPC_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].VpcId' --region ${AWS_REGION} --output text) && echo "AWS_VPC_ID: \"$AWS_VPC_ID\""$ AWS_VPC_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].VpcId' --region ${AWS_REGION} --output text) && echo "AWS_VPC_ID: \"$AWS_VPC_ID\""Copy to Clipboard Copied! Toggle word wrap Toggle overflow Retrieve and record the AWS security group IDs:
AWS_SG_IDS=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' --region $AWS_REGION --output json | jq -r '.[][][]' | paste -sd ",") && echo "AWS_SG_IDS: \"$AWS_SG_IDS\""$ AWS_SG_IDS=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' --region $AWS_REGION --output json | jq -r '.[][][]' | paste -sd ",") && echo "AWS_SG_IDS: \"$AWS_SG_IDS\""Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
In the OpenShift Container Platform web console, navigate to Operators
Installed Operators. - Select the OpenShift sandboxed containers Operator from the list of operators.
- Click the Import icon (+) in the top right corner.
In the Import YAML window, paste the following YAML manifest:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Defines the default instance type that is used when a type is not defined in the workload.
- 2
- Specify the instance types, without spaces, for creating the pod. This allows you to define smaller instance types for workloads that need less memory and fewer CPUs or larger instance types for larger workloads.
- 3
- Optional: By default, this value is populated when you run the
KataConfigCR, using an AMI ID based on your cluster credentials. If you create your own AMI, specify the correct AMI ID. - 4
- Specify the
AWS_REGIONvalue you retrieved. - 5
- Specify the
AWS_SUBNET_IDvalue you retrieved. - 6
- Specify the
AWS_VPC_IDvalue you retrieved. - 7
- Specify the
AWS_SG_IDSvalue you retrieved. - 8
- Specify the maximum number of peer pods that can be created per node. The default value is
10. - 9
- You can configure custom tags as
key:valuepairs for pod VM instances to track peer pod costs or to identify peer pods in different clusters.
- Click Save to apply the changes.
-
Navigate to Workloads
ConfigMaps to view the new config map.
3.2.5. Selecting a custom peer pod VM image Copiar enlaceEnlace copiado en el portapapeles!
You can select a custom peer pod virtual machine (VM) image, tailored to your workload requirements by adding an annotation to the pod manifest. The custom image overrides the default image specified in the peer pods config map.
Prerequisites
- The ID of the custom pod VM image to use, compatible with the cloud provider or hypervisor, is available.
Procedure
-
In the OpenShift Container Platform web console, navigate to Operators
Installed Operators. - Select the OpenShift sandboxed containers Operator from the list of operators.
- Click the Import icon (+) in the top right corner.
In the Import YAML window, paste the following YAML manifest:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click Save to apply the changes.
3.2.6. Customizing the Kata agent policy Copiar enlaceEnlace copiado en el portapapeles!
The Kata agent policy is a security mechanism that controls agent API requests for pods running with the Kata runtime. Written in Rego and enforced by the Kata agent within the pod virtual machine (VM), this policy determines which operations are allowed or denied.
You can override the default policy with a custom one for specific use cases, such as development and testing where security is not a concern. For example, you might run in an environment where the control plane can be trusted. You can apply a custom policy in several ways:
- Embedding it in the pod VM image.
- Patching the peer pods config map.
- Adding an annotation to the workload pod YAML.
For production systems, the preferred method is to use initdata to override the Kata agent policy. The following procedure applies a custom policy to an individual pod using the io.katacontainers.config.agent.policy annotation. The policy is provided in Base64-encoded Rego format. This approach overrides the default policy at pod creation without modifying the pod VM image.
A custom policy replaces the default policy entirely. To modify only specific APIs, include the full policy and adjust the relevant rules.
Procedure
Create a
policy.regofile with your custom policy. The following example shows all configurable APIs, withexecandlogenabled for demonstration:Copy to Clipboard Copied! Toggle word wrap Toggle overflow This policy enables the
exec(ExecProcessRequest) andlog(ReadStreamRequest) APIs. Adjust thetrueorfalsevalues to customize the policy further based on your needs.Convert the
policy.regofile to a Base64-encoded string by running the following command:base64 -w0 policy.rego
$ base64 -w0 policy.regoCopy to Clipboard Copied! Toggle word wrap Toggle overflow Save the output for use in the yaml file.
-
In the OpenShift Container Platform web console, navigate to Operators
Installed Operators. - Select the OpenShift sandboxed containers Operator from the list of operators.
- Click the Import icon (+) in the top right corner.
In the Import YAML window, paste the following YAML manifest and add the Base64-encoded policy to it:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click Save to apply the changes.
3.2.7. Creating the KataConfig custom resource Copiar enlaceEnlace copiado en el portapapeles!
You must create the KataConfig custom resource (CR) to install kata-remote as a RuntimeClass on your worker nodes.
The kata-remote runtime class is installed on all worker nodes by default. If you want to install kata-remote on specific nodes, you can add labels to those nodes and then define the label in the KataConfig CR.
OpenShift sandboxed containers installs kata-remote as a secondary, optional runtime on the cluster and not as the primary runtime.
Creating the KataConfig CR automatically reboots the worker nodes. The reboot can take from 10 to more than 60 minutes. The following factors might increase the reboot time:
- A larger OpenShift Container Platform deployment with a greater number of worker nodes.
- Activation of the BIOS and Diagnostics utility.
- Deployment on a hard disk drive rather than an SSD.
- Deployment on physical nodes such as bare metal, rather than on virtual nodes.
- A slow CPU and network.
Prerequisites
-
You have access to the cluster as a user with the
cluster-adminrole. - Optional: You have installed the Node Feature Discovery Operator if you want to enable node eligibility checks.
Procedure
-
In the OpenShift Container Platform web console, navigate to Operators
Installed Operators. - Select the OpenShift sandboxed containers Operator.
- On the KataConfig tab, click Create KataConfig.
Enter the following details:
-
Name: Optional: The default name is
example-kataconfig. -
Labels: Optional: Enter any relevant, identifying attributes to the
KataConfigresource. Each label represents a key-value pair. - enablePeerPods: Select for public cloud, IBM Z®, and IBM® LinuxONE deployments.
kataConfigPoolSelector. Optional: To install
kata-remoteon selected nodes, add a match expression for the labels on the selected nodes:- Expand the kataConfigPoolSelector area.
- In the kataConfigPoolSelector area, expand matchExpressions. This is a list of label selector requirements.
- Click Add matchExpressions.
- In the Key field, enter the label key the selector applies to.
-
In the Operator field, enter the key’s relationship to the label values. Valid operators are
In,NotIn,Exists, andDoesNotExist. - Expand the Values area and then click Add value.
-
In the Value field, enter
trueorfalsefor key label value.
-
logLevel: Define the level of log data retrieved for nodes with the
kata-remoteruntime class.
-
Name: Optional: The default name is
Click Create. The
KataConfigCR is created and installs thekata-remoteruntime class on the worker nodes.Wait for the
kata-remoteinstallation to complete and the worker nodes to reboot before verifying the installation.
Verification
-
On the KataConfig tab, click the
KataConfigCR to view its details. Click the YAML tab to view the
statusstanza.The
statusstanza contains theconditionsandkataNodeskeys. The value ofstatus.kataNodesis an array of nodes, each of which lists nodes in a particular state ofkata-remoteinstallation. A message appears each time there is an update.Click Reload to refresh the YAML.
When all workers in the
status.kataNodesarray display the valuesinstalledandconditions.InProgress: Falsewith no specified reason, thekata-remoteis installed on the cluster.
Additional resources
Verifying the pod VM image
After kata-remote is installed on your cluster, the OpenShift sandboxed containers Operator creates a pod VM image, which is used to create peer pods. This process can take a long time because the image is created on the cloud instance. You can verify that the pod VM image was created successfully by checking the config map that you created for the cloud provider.
Procedure
-
Navigate to Workloads
ConfigMaps. - Click the provider config map to view its details.
- Click the YAML tab.
Check the
statusstanza of the YAML file.If the
PODVM_AMI_IDparameter is populated, the pod VM image was created successfully.
Troubleshooting
Retrieve the events log by running the following command:
oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
$ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creationCopy to Clipboard Copied! Toggle word wrap Toggle overflow Retrieve the job log by running the following command:
oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation
$ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creationCopy to Clipboard Copied! Toggle word wrap Toggle overflow
If you cannot resolve the issue, submit a Red Hat Support case and attach the output of both logs.
3.2.8. Configuring workload objects Copiar enlaceEnlace copiado en el portapapeles!
You must configure OpenShift sandboxed containers workload objects by setting kata-remote as the runtime class for the following pod-templated objects:
-
Podobjects -
ReplicaSetobjects -
ReplicationControllerobjects -
StatefulSetobjects -
Deploymentobjects -
DeploymentConfigobjects
Do not deploy workloads in an Operator namespace. Create a dedicated namespace for these resources.
You can define whether the workload should be deployed using the default instance type, which you defined in the config map, by adding an annotation to the YAML file.
If you do not want to define the instance type manually, you can add an annotation to use an automatic instance type, based on the memory available.
Prerequisites
-
You have created the
KataConfigcustom resource (CR).
Procedure
-
In the OpenShift Container Platform web console, navigate to Workloads
workload type, for example, Pods. - On the workload type page, click an object to view its details.
- Click the YAML tab.
Add
spec.runtimeClassName: kata-remoteto the manifest of each pod-templated workload object as in the following example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add an annotation to the pod-templated object to use a manually defined instance type or an automatic instance type:
To use a manually defined instance type, add the following annotation:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow To use an automatic instance type, add the following annotations:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Define the amount of memory available for the workload to use. The workload will run on an automatic instance type based on the amount of memory available.
Click Save to apply the changes.
OpenShift Container Platform creates the workload object and begins scheduling it.
Verification
-
Inspect the
spec.runtimeClassNamefield of a pod-templated object. If the value iskata-remote, then the workload is running on OpenShift sandboxed containers, using peer pods.
3.3. Deploying OpenShift sandboxed containers by using the command line Copiar enlaceEnlace copiado en el portapapeles!
You can deploy OpenShift sandboxed containers on AWS by using the command line interface (CLI) to perform the following tasks:
- Install the OpenShift sandboxed containers Operator.
- Optional: Enable ports 15150 and 9000 to allow internal communication with peer pods.
- Optional: Create the peer pods secret if you uninstalled the Cloud Credential Operator, which is installed with the OpenShift sandboxed containers Operator.
- Optional: Select a custom pod VM image.
- Create the peer pods config map.
- Optional: Customize the Kata agent policy.
-
Create the
KataConfigcustom resource. - Optional: Modify the number of virtual machines running on each worker node.
- Configure the OpenShift sandboxed containers workload objects.
3.3.1. Installing the OpenShift sandboxed containers Operator Copiar enlaceEnlace copiado en el portapapeles!
You can install the OpenShift sandboxed containers Operator by using the CLI.
Prerequisites
-
You have installed the OpenShift CLI (
oc). -
You have access to the cluster as a user with the
cluster-adminrole.
Procedure
Create an
osc-namespace.yamlmanifest file:apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create the namespace by running the following command:
oc apply -f osc-namespace.yaml
$ oc apply -f osc-namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create an
osc-operatorgroup.yamlmanifest file:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the operator group by running the following command:
oc apply -f osc-operatorgroup.yaml
$ oc apply -f osc-operatorgroup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create an
osc-subscription.yamlmanifest file:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the subscription by running the following command:
oc apply -f osc-subscription.yaml
$ oc apply -f osc-subscription.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that the Operator is correctly installed by running the following command:
oc get csv -n openshift-sandboxed-containers-operator
$ oc get csv -n openshift-sandboxed-containers-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow This command can take several minutes to complete.
Watch the process by running the following command:
watch oc get csv -n openshift-sandboxed-containers-operator
$ watch oc get csv -n openshift-sandboxed-containers-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
NAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.9.0 1.8.1 Succeeded
NAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.9.0 1.8.1 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.2. Enabling ports for AWS Copiar enlaceEnlace copiado en el portapapeles!
You must enable ports 15150 and 9000 to allow internal communication with peer pods running on AWS.
Prerequisites
- You have installed the OpenShift sandboxed containers Operator.
- You have installed the AWS command line tool.
-
You have access to the cluster as a user with the
cluster-adminrole.
Procedure
Log in to your OpenShift Container Platform cluster and retrieve the instance ID:
INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' \ -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' \ -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')Copy to Clipboard Copied! Toggle word wrap Toggle overflow Retrieve the AWS region:
AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}')$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow Retrieve the security group IDs and store them in an array:
AWS_SG_IDS=($(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \ --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \ --output text --region $AWS_REGION))$ AWS_SG_IDS=($(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} \ --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' \ --output text --region $AWS_REGION))Copy to Clipboard Copied! Toggle word wrap Toggle overflow For each security group ID, authorize the peer pods shim to access kata-agent communication, and set up the peer pods tunnel:
for AWS_SG_ID in "${AWS_SG_IDS[@]}"; do \ aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 15150 --source-group $AWS_SG_ID --region $AWS_REGION \ aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 9000 --source-group $AWS_SG_ID --region $AWS_REGION \ done$ for AWS_SG_ID in "${AWS_SG_IDS[@]}"; do \ aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 15150 --source-group $AWS_SG_ID --region $AWS_REGION \ aws ec2 authorize-security-group-ingress --group-id $AWS_SG_ID --protocol tcp --port 9000 --source-group $AWS_SG_ID --region $AWS_REGION \ doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow
The ports are now enabled.
3.3.3. Creating the peer pods secret Copiar enlaceEnlace copiado en el portapapeles!
When the peer pods secret is empty and the Cloud Credential Operator (CCO) is installed, the OpenShift sandboxed containers Operator uses the CCO to retrieve the secret. If you have uninstalled the CCO, you must create the peer pods secret for OpenShift sandboxed containers manually or the peer pods will fail to operate.
The secret stores credentials for creating the pod virtual machine (VM) image and peer pod instances.
By default, the OpenShift sandboxed containers Operator creates the secret based on the credentials used to create the cluster. However, you can manually create a secret that uses different credentials.
Prerequisites
You have the following values generated by using the AWS console:
-
AWS_ACCESS_KEY_ID -
AWS_SECRET_ACCESS_KEY
-
Procedure
Create a
peer-pods-secret.yamlmanifest file according to the following example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the secret by running the following command:
oc apply -f peer-pods-secret.yaml
$ oc apply -f peer-pods-secret.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.4. Creating the peer pods config map Copiar enlaceEnlace copiado en el portapapeles!
You must create the peer pods config map for OpenShift sandboxed containers.
Prerequisites
- You have your Amazon Machine Image (AMI) ID if you are not using the default AMI ID based on your cluster credentials.
Procedure
Obtain the following values from your AWS instance:
Retrieve and record the instance ID:
INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')$ INSTANCE_ID=$(oc get nodes -l 'node-role.kubernetes.io/worker' -o jsonpath='{.items[0].spec.providerID}' | sed 's#[^ ]*/##g')Copy to Clipboard Copied! Toggle word wrap Toggle overflow This is used to retrieve other values for the secret object.
Retrieve and record the AWS region:
AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}') && echo "AWS_REGION: \"$AWS_REGION\""$ AWS_REGION=$(oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.aws.region}') && echo "AWS_REGION: \"$AWS_REGION\""Copy to Clipboard Copied! Toggle word wrap Toggle overflow Retrieve and record the AWS subnet ID:
AWS_SUBNET_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SubnetId' --region ${AWS_REGION} --output text) && echo "AWS_SUBNET_ID: \"$AWS_SUBNET_ID\""$ AWS_SUBNET_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SubnetId' --region ${AWS_REGION} --output text) && echo "AWS_SUBNET_ID: \"$AWS_SUBNET_ID\""Copy to Clipboard Copied! Toggle word wrap Toggle overflow Retrieve and record the AWS VPC ID:
AWS_VPC_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].VpcId' --region ${AWS_REGION} --output text) && echo "AWS_VPC_ID: \"$AWS_VPC_ID\""$ AWS_VPC_ID=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].VpcId' --region ${AWS_REGION} --output text) && echo "AWS_VPC_ID: \"$AWS_VPC_ID\""Copy to Clipboard Copied! Toggle word wrap Toggle overflow Retrieve and record the AWS security group IDs:
AWS_SG_IDS=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' --region $AWS_REGION --output json | jq -r '.[][][]' | paste -sd ",") && echo "AWS_SG_IDS: \"$AWS_SG_IDS\""$ AWS_SG_IDS=$(aws ec2 describe-instances --instance-ids ${INSTANCE_ID} --query 'Reservations[*].Instances[*].SecurityGroups[*].GroupId' --region $AWS_REGION --output json | jq -r '.[][][]' | paste -sd ",") && echo "AWS_SG_IDS: \"$AWS_SG_IDS\""Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Create a
peer-pods-cm.yamlmanifest file according to the following example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Defines the default instance type that is used when a type is not defined in the workload.
- 2
- Specify the instance types, without spaces, for creating the pod. This allows you to define smaller instance types for workloads that need less memory and fewer CPUs or larger instance types for larger workloads.
- 3
- Optional: By default, this value is populated when you run the
KataConfigCR, using an AMI ID based on your cluster credentials. If you create your own AMI, specify the correct AMI ID. - 4
- Specify the
AWS_REGIONvalue you retrieved. - 5
- Specify the
AWS_SUBNET_IDvalue you retrieved. - 6
- Specify the
AWS_VPC_IDvalue you retrieved. - 7
- Specify the
AWS_SG_IDSvalue you retrieved. - 8
- Specify the maximum number of peer pods that can be created per node. The default value is
10. - 9
- You can configure custom tags as
key:valuepairs for pod VM instances to track peer pod costs or to identify peer pods in different clusters.
Create the config map by running the following command:
oc apply -f peer-pods-cm.yaml
$ oc apply -f peer-pods-cm.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.5. Selecting a custom peer pod VM image Copiar enlaceEnlace copiado en el portapapeles!
You can select a custom peer pod virtual machine (VM) image, tailored to your workload requirements by adding an annotation to the pod manifest. The custom image overrides the default image specified in the peer pods config map.
Prerequisites
- The ID of the custom pod VM image to use, compatible with the cloud provider or hypervisor, is available.
Procedure
Edit the pod manifest by adding the
io.katacontainers.config.hypervisor.imageannotation and save it in apod-manifest.yamlfile:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the pod by running the following command:
oc apply -f pod-manifest.yaml
$ oc apply -f pod-manifest.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.6. Customizing the Kata agent policy Copiar enlaceEnlace copiado en el portapapeles!
The Kata agent policy is a security mechanism that controls agent API requests for pods running with the Kata runtime. Written in Rego and enforced by the Kata agent within the pod virtual machine (VM), this policy determines which operations are allowed or denied.
You can override the default policy with a custom one for specific use cases, such as development and testing where security is not a concern. For example, you might run in an environment where the control plane can be trusted. You can apply a custom policy in several ways:
- Embedding it in the pod VM image.
- Patching the peer pods config map.
- Adding an annotation to the workload pod YAML.
For production systems, the preferred method is to use initdata to override the Kata agent policy. The following procedure applies a custom policy to an individual pod using the io.katacontainers.config.agent.policy annotation. The policy is provided in Base64-encoded Rego format. This approach overrides the default policy at pod creation without modifying the pod VM image.
A custom policy replaces the default policy entirely. To modify only specific APIs, include the full policy and adjust the relevant rules.
Procedure
Create a
policy.regofile with your custom policy. The following example shows all configurable APIs, withexecandlogenabled for demonstration:Copy to Clipboard Copied! Toggle word wrap Toggle overflow This policy enables the
exec(ExecProcessRequest) andlog(ReadStreamRequest) APIs. Adjust thetrueorfalsevalues to customize the policy further based on your needs.Convert the
policy.regofile to a Base64-encoded string by running the following command:base64 -w0 policy.rego
$ base64 -w0 policy.regoCopy to Clipboard Copied! Toggle word wrap Toggle overflow Save the output for use in the yaml file.
Add the Base64-encoded policy to a
my-pod.yamlpod specification file:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the pod manifest by running the following command:
oc apply -f my-pod.yaml
$ oc apply -f my-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.7. Creating the KataConfig custom resource Copiar enlaceEnlace copiado en el portapapeles!
You must create the KataConfig custom resource (CR) to install kata-remote as a runtime class on your worker nodes.
Creating the KataConfig CR triggers the OpenShift sandboxed containers Operator to do the following:
-
Create a
RuntimeClassCR namedkata-remotewith a default configuration. This enables users to configure workloads to usekata-remoteas the runtime by referencing the CR in theRuntimeClassNamefield. This CR also specifies the resource overhead for the runtime.
OpenShift sandboxed containers installs kata-remote as a secondary, optional runtime on the cluster and not as the primary runtime.
Creating the KataConfig CR automatically reboots the worker nodes. The reboot can take from 10 to more than 60 minutes. Factors that impede reboot time are as follows:
- A larger OpenShift Container Platform deployment with a greater number of worker nodes.
- Activation of the BIOS and Diagnostics utility.
- Deployment on a hard disk drive rather than an SSD.
- Deployment on physical nodes such as bare metal, rather than on virtual nodes.
- A slow CPU and network.
Prerequisites
-
You have access to the cluster as a user with the
cluster-adminrole.
Procedure
Create an
example-kataconfig.yamlmanifest file according to the following example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Optional: If you have applied node labels to install
kata-remoteon specific nodes, specify the key and value, for example,osc: 'true'.
Create the
KataConfigCR by running the following command:oc apply -f example-kataconfig.yaml
$ oc apply -f example-kataconfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow The new
KataConfigCR is created and installskata-remoteas a runtime class on the worker nodes.Wait for the
kata-remoteinstallation to complete and the worker nodes to reboot before verifying the installation.Monitor the installation progress by running the following command:
watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"Copy to Clipboard Copied! Toggle word wrap Toggle overflow When the status of all workers under
kataNodesisinstalledand the conditionInProgressisFalsewithout specifying a reason, thekata-remoteis installed on the cluster.Verify the daemon set by running the following command:
oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
$ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-dsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Verify the runtime classes by running the following command:
oc get runtimeclass
$ oc get runtimeclassCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
NAME HANDLER AGE kata kata 152m kata-remote kata-remote 152m
NAME HANDLER AGE kata kata 152m kata-remote kata-remote 152mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.8. Modifying the number of peer pod VMs per node Copiar enlaceEnlace copiado en el portapapeles!
You can modify the limit of peer pod virtual machines (VMs) per node by editing the peerpodConfig custom resource (CR).
Procedure
Check the current limit by running the following command:
oc get peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \ -o jsonpath='{.spec.limit}{"\n"}'$ oc get peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \ -o jsonpath='{.spec.limit}{"\n"}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Modify the
limitattribute of thepeerpodConfigCR by running the following command:oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \ --type merge --patch '{"spec":{"limit":"<value>"}}'$ oc patch peerpodconfig peerpodconfig-openshift -n openshift-sandboxed-containers-operator \ --type merge --patch '{"spec":{"limit":"<value>"}}'1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Replace <value> with the limit you want to define.
Verifying the pod VM image
After kata-remote is installed on your cluster, the OpenShift sandboxed containers Operator creates a pod VM image, which is used to create peer pods. This process can take a long time because the image is created on the cloud instance. You can verify that the pod VM image was created successfully by checking the config map that you created for the cloud provider.
Procedure
Obtain the config map you created for the peer pods:
oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yaml
$ oc get configmap peer-pods-cm -n openshift-sandboxed-containers-operator -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Check the
statusstanza of the YAML file.If the
PODVM_AMI_IDparameter is populated, the pod VM image was created successfully.
Troubleshooting
Retrieve the events log by running the following command:
oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creation
$ oc get events -n openshift-sandboxed-containers-operator --field-selector involvedObject.name=osc-podvm-image-creationCopy to Clipboard Copied! Toggle word wrap Toggle overflow Retrieve the job log by running the following command:
oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creation
$ oc logs -n openshift-sandboxed-containers-operator jobs/osc-podvm-image-creationCopy to Clipboard Copied! Toggle word wrap Toggle overflow
If you cannot resolve the issue, submit a Red Hat Support case and attach the output of both logs.
3.3.9. Configuring workload objects Copiar enlaceEnlace copiado en el portapapeles!
You must configure OpenShift sandboxed containers workload objects by setting kata-remote as the runtime class for the following pod-templated objects:
-
Podobjects -
ReplicaSetobjects -
ReplicationControllerobjects -
StatefulSetobjects -
Deploymentobjects -
DeploymentConfigobjects
Do not deploy workloads in an Operator namespace. Create a dedicated namespace for these resources.
You can define whether the workload should be deployed using the default instance type, which you defined in the config map, by adding an annotation to the YAML file.
If you do not want to define the instance type manually, you can add an annotation to use an automatic instance type, based on the memory available.
Prerequisites
-
You have created the
KataConfigcustom resource (CR).
Procedure
Add
spec.runtimeClassName: kata-remoteto the manifest of each pod-templated workload object as in the following example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add an annotation to the pod-templated object to use a manually defined instance type or an automatic instance type:
To use a manually defined instance type, add the following annotation:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specify the instance type that you defined in the config map.
To use an automatic instance type, add the following annotations:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Define the amount of memory available for the workload to use. The workload will run on an automatic instance type based on the amount of memory available.
Apply the changes to the workload object by running the following command:
oc apply -f <object.yaml>
$ oc apply -f <object.yaml>Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform creates the workload object and begins scheduling it.
Verification
-
Inspect the
spec.runtimeClassNamefield of a pod-templated object. If the value iskata-remote, then the workload is running on OpenShift sandboxed containers, using peer pods.