DOCSEARCHbyAlgolia
Submit Docs

OKD Project Documentation

repository·master·Indexed 24 days ago

https://github.com/okd-project/okd

OKD is the community distribution of Kubernetes that powers Red Hat's OpenShift, optimized for continuous application development and multi-tenant deployment. This documentation provides installation and configuration guides for various environments, including Azure Cloud Shell, OpenStack via Terraform, VMware vSphere using govc, and Bare Metal User-Provisioned Infrastructure (UPI).

Tokens
21.6K
Snippets
52
Records
81
Agent score
84%

What's inside OKD

  1. Bare Metal UPI - Tips & Tricks Overview

    master
    The Bare Metal User-Provisioned Infrastructure (UPI) guides provide workarounds and optimizations for OKD deployments on bare metal hardware. Because bare metal environments vary significantly, these guides address common scenarios where standard OKD installer assumptions may fail, such as specific network interface configurations, DNS issues in Fedora CoreOS (FCOS), and hostname resolution.

  2. Why manual iptables manipulation via MachineConfig is discouraged

    master

    Attempting to manage node firewalls by deploying MachineConfig to manipulate iptables is unreliable in OKD.

    If you are using the default networking setups like OpenShift SDN or OVNKubernetes, the CNI manages the iptables ruleset. For example, in OpenShift SDN, whenever the SDN updates its rules, it updates them at index 0, effectively prepending its rules before any custom rules you have injected. This circumvents your filtering logic.

    To avoid network instability or security bypasses, do not blindly configure iptables; instead, integrate your rules into the CNI manually or use the provider's supported configuration mechanisms.

  3. Use Source-to-Image (S2I) to build applications

    master

    Source-to-Image (S2I) is a tool that allows you to deploy applications by providing only the source code. It combines your source code with an existing S2I-enabled container image to produce a new, runnable image.

    Commonly available S2I builder images include:

    • Ruby
    • Python
    • Node.js
    • PHP
    • Perl
    • WildFly
    • MySQL
    • MongoDB
    • PostgreSQL
    • MariaDB

  4. Understand OKD bootstrap vs OCP bootstrap

    master

    A key architectural difference between OKD and OCP is the underlying operating system:

    • OCP: Uses RHEL CoreOS (RHCOS), which includes kubelet, crio, and Machine Config Daemon by default.
    • OKD: Uses Fedora CoreOS (FCOS). Because FCOS is more versatile, OKD must update the plain FCOS to include OKD-specific content.

    The Bootstrap Process in OKD:

    1. The release-image-download.service pulls the machine-os-content image from the payload.
    2. It extracts the ostree commit and pivots the bootstrap node into it.
    3. For control plane and worker nodes, the machine-config-firstboot.service performs a similar update early in the process.

  5. Understand OKD default security controls

    master

    OKD implements several security defaults to isolate workloads:

    • Non-root execution: Containers run as a unique, non-root user. They cannot access host resources, run privileged, or become root.
    • Resource Limits: CPU and memory limits are enforced by the system.
    • Storage Isolation: Persistent storage is assigned a unique SELinux label to prevent cross-project access.
    • Project Isolation: Containers in different projects are isolated from each other by default.
    • Build Controls: While regular users can run builds, Docker builds (which often run as root) can be restricted via builds/docker and builds/custom policy resources.

  6. Operator availability in OKD vs OCP

    master
    Some optional operators available in Red Hat OpenShift Container Platform (OCP) are not available in OKD. Users should refer to the official OKD technical documentation for details on operator availability. An OKD-specific catalog containing community versions of these operators is currently in development.

  7. Inject DNS Configuration into the Bootstrap Ignition

    master

    The bootstrap node is a 'snowflake' and does not use MachineConfig. You must manually inject the DNS configuration into the bootstrap.ign file. This step must be performed after running openshift-install create ignition-configs.

    It is recommended to use ignition.config.merge or tools like jq or yq to merge the following JSON structure into your bootstrap.ign rather than editing the file by hand.

    {
  "storage": {
    "links": [
      {
        "group": {},
        "path": "/etc/resolv.conf",
        "user": {},
        "target": "../run/systemd/resolve/resolv.conf"
      }
    ],
    "files": [
      {
        "overwrite": true,
        "path": "/etc/systemd/resolved.conf.d/50-no-dns-stub.conf",
        "user": {
          "name": "root"
        },
        "contents": {
          "source": "data:text/plain;charset=utf-8;base64,W1Jlc29sdmVdCkROU1N0dWJMaXN0ZW5lcj1ubwo="
        },
        "mode": 420
      },
      {
        "overwrite": true,
        "path": "/etc/systemd/resolved.conf.d/75-static-dns-servers.conf",
        "user": {
          "name": "root"
        },
        "contents": {
          "source": "data:text/plain;charset=utf-8;base64,<INJECT_YOUR_BASE_64_HERE>"
        },
        "mode": 420
      }
    ]
  }
}

  8. Configure DNS Reverse Zone records for OKD

    master

    Create a reverse zone file (e.g., /var/named/zones/db.192.168.100) to map IP addresses back to FQDNs.

    Replace BASTION_LAST_OCTECT_IP, BOOTSTRAP_SERVER_LAST_OCTECT_IP, etc., with the last octet of the respective IP addresses, and replace FQDN placeholders with the actual hostnames.

    $TTL    604800
@       IN      SOA     ns1.example.com. admin.example.com. (
                  6     ; Serial
             604800     ; Refresh
              86400     ; Retry
            2419200     ; Expire
             604800     ; Negative Cache TTL
)

; name servers - NS records
    IN      NS      ns1.example.com.

; name servers - PTR records
BASTION_LAST_OCTECT_IP    IN    PTR    ns1.example.com.

; OpenShift Container Platform Cluster - PTR records
BOOTSTRAP_SERVER_LAST_OCTECT_IP    IN    PTR    BOOTSTRAP_SERVER_FQDN.
CONTROL_PLANE_0_LAST_OCTECT_IP    IN    PTR    CONTROL_PLANE_0_FQDN.
CONTROL_PLANE_1_LAST_OCTECT_IP    IN    PTR    CONTROL_PLANE_1_FQDN.
CONTROL_PLANE_2_LAST_OCTECT_IP    IN    PTR    CONTROL_PLANE_2_FQDN.
COMPUTE_NODE_0_LAST_OCTECT_IP    IN    PTR    COMPUTE_NODE_0_FQDN.
COMPUTE_NODE_1_LAST_OCTECT_IP    IN    PTR    COMPUTE_NODE_1_FQDN.

  9. Provision OKD on vSphere using UPI and Terraform

    master

    This guide outlines the process for provisioning Fedora CoreOS (FCOS) on VMware vSphere and installing OKD using User-Provisioned Infrastructure (UPI) and Terraform. The process involves preparing DNS/DHCP, setting up a load balancer, generating ignition configurations, and using Terraform to deploy the virtual machines.

    High-Level Workflow

    1. Prepare Environment: Configure DNS, DHCP, and a Load Balancer (e.g., HAProxy).
    2. Get Tools: Download oc and the openshift-install binary.
    3. Configure Installation: Create install-config.yaml and generate ignition files.
    4. Deploy Infrastructure: Use Terraform to provision VMs.
    5. Bootstrap: Wait for the bootstrap node to complete, then run a second Terraform apply to destroy the bootstrap VM.
    6. Finalize: Wait for the full cluster installation to complete.

  10. Configure cluster traffic to use a private network interface

    master

    In bare metal deployments with dual NICs (e.g., eno1 for public and eno2 for private), OKD may default to using the public interface for the Node's InternalIP. Because other nodes use InternalIP (not DNS) to resolve peer addresses, cluster traffic may inadvertently traverse the public network.

    To ensure cluster-internal traffic traverses the private network, you must manually set the Kubelet IP. Refer to the Nodes with custom IP guide for specific implementation steps.

  11. Install OKD SCOS using installer-provisioned resources

    master

    For cloud-based installations using installer-provisioned resources, use the openshift-install binary.

    Pull Secret Note: During installation, you may be prompted for a pull-secret. For OKD4, you can either provide the pull-secret used for your registry or use the following dummy JSON to bypass the required value check: {"auths":{"fake":{"auth":"aWQ6cGFzcwo="}}}

    Upon successful completion (typically ~30 minutes on AWS), the installer will output the console URL, admin username, and admin password.

    $ openshift-install create cluster

  12. Enable or Disable Network Interfaces via MachineConfigs

    master

    In OKD/FCOS, network interfaces are managed by NetworkManager. You can enable or disable specific interfaces (such as unused IPMI ports or misconfigured physical adapters that delay startup via DHCP) by deploying MachineConfig objects.

    To disable an interface, you must instruct NetworkManager to mark it as unmanaged. This is achieved by placing a configuration file in /etc/NetworkManager/conf.d/ using a MachineConfig with an ignition storage payload.

    Deployment Timing:

    • Running Cluster: Deploy the MachineConfig directly to the cluster.
    • Cluster Installation (Bare Metal): Include the YAML within the manifests folder after running openshift-install create manifests but before running openshift-install create ignition-configs.
    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: okd-configure-master-disable-XYZ-network-interface
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,<YOUR_BASE64_HERE>
          mode: 420
          path: /etc/NetworkManager/conf.d/50-disable-XYZ-interfaces.conf