ROSA에 대해 알아보기


Red Hat OpenShift Service on AWS 4

AWS의 Red Hat OpenShift Service에 대해 알아보기

Red Hat OpenShift Documentation Team

초록

이 문서에는 클러스터 생성 및 애플리케이션 배포에 대한 워크샵이 포함되어 있습니다.

1장. 클러스터 워크샵 생성

1.1. 클러스터 생성

AWS(ROSA) 클러스터에 샘플 Red Hat OpenShift Service를 배포하려면 이 워크샵에 따르십시오. 그런 다음 다음 워크샵에서 클러스터를 사용할 수 있습니다.

워크샵 목표

  • 클러스터 사전 요구 사항을 생성하는 방법을 알아봅니다.

    • 샘플 VPC(가상 프라이빗 클라우드) 생성
    • 샘플 OpenID Connect(OIDC) 리소스 생성
  • 환경 변수 샘플 생성
  • 샘플 ROSA 클러스터 배포

사전 요구 사항

  • ROSA 버전 1.2.31 이상
  • AWS(Amazon Web Service) 명령줄 인터페이스(CLI)
  • ROSA CLI (rosa)

1.1.1. 클러스터 사전 요구 사항 생성

ROSA 클러스터를 배포하기 전에 VPC 및 OIDC 리소스가 모두 있어야 합니다. 먼저 이러한 리소스를 만들 것입니다. ROSA는 BYO-VPC(Bring Your Own VPC) 모델을 사용합니다.

1.1.1.1. VPC 생성
  1. ROSA를 사용할 수 있는 리전을 사용하도록 AWS CLI(aws)가 구성되어 있는지 확인합니다. 다음 명령을 실행하여 AWS CLI에서 지원하는 리전을 참조하십시오.

    $ rosa list regions --hosted-cp
    Copy to Clipboard Toggle word wrap
  2. VPC를 생성합니다. 이 워크샵에서 다음 스크립트 는 VPC 및 필요한 구성 요소를 생성합니다. aws CLI에 구성된 리전을 사용합니다.

    #!/bin/bash
    
    set -e
    ##########
    # This script will create the network requirements for a ROSA cluster. This will be
    # a public cluster. This creates:
    # - VPC
    # - Public and private subnets
    # - Internet Gateway
    # - Relevant route tables
    # - NAT Gateway
    #
    # This will automatically use the region configured for the aws cli
    #
    ##########
    
    VPC_CIDR=10.0.0.0/16
    PUBLIC_CIDR_SUBNET=10.0.1.0/24
    PRIVATE_CIDR_SUBNET=10.0.0.0/24
    
    # Create VPC
    echo -n "Creating VPC..."
    VPC_ID=$(aws ec2 create-vpc --cidr-block $VPC_CIDR --query Vpc.VpcId --output text)
    
    # Create tag name
    aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=$CLUSTER_NAME
    
    # Enable dns hostname
    aws ec2 modify-vpc-attribute --vpc-id $VPC_ID --enable-dns-hostnames
    echo "done."
    
    # Create Public Subnet
    echo -n "Creating public subnet..."
    PUBLIC_SUBNET_ID=$(aws ec2 create-subnet --vpc-id $VPC_ID --cidr-block $PUBLIC_CIDR_SUBNET --query Subnet.SubnetId --output text)
    
    aws ec2 create-tags --resources $PUBLIC_SUBNET_ID --tags Key=Name,Value=$CLUSTER_NAME-public
    echo "done."
    
    # Create private subnet
    echo -n "Creating private subnet..."
    PRIVATE_SUBNET_ID=$(aws ec2 create-subnet --vpc-id $VPC_ID --cidr-block $PRIVATE_CIDR_SUBNET --query Subnet.SubnetId --output text)
    
    aws ec2 create-tags --resources $PRIVATE_SUBNET_ID --tags Key=Name,Value=$CLUSTER_NAME-private
    echo "done."
    
    # Create an internet gateway for outbound traffic and attach it to the VPC.
    echo -n "Creating internet gateway..."
    IGW_ID=$(aws ec2 create-internet-gateway --query InternetGateway.InternetGatewayId --output text)
    echo "done."
    
    aws ec2 create-tags --resources $IGW_ID --tags Key=Name,Value=$CLUSTER_NAME
    
    aws ec2 attach-internet-gateway --vpc-id $VPC_ID --internet-gateway-id $IGW_ID > /dev/null 2>&1
    echo "Attached IGW to VPC."
    
    # Create a route table for outbound traffic and associate it to the public subnet.
    echo -n "Creating route table for public subnet..."
    PUBLIC_ROUTE_TABLE_ID=$(aws ec2 create-route-table --vpc-id $VPC_ID --query RouteTable.RouteTableId --output text)
    
    aws ec2 create-tags --resources $PUBLIC_ROUTE_TABLE_ID --tags Key=Name,Value=$CLUSTER_NAME
    echo "done."
    
    aws ec2 create-route --route-table-id $PUBLIC_ROUTE_TABLE_ID --destination-cidr-block 0.0.0.0/0 --gateway-id $IGW_ID > /dev/null 2>&1
    echo "Created default public route."
    
    aws ec2 associate-route-table --subnet-id $PUBLIC_SUBNET_ID --route-table-id $PUBLIC_ROUTE_TABLE_ID > /dev/null 2>&1
    echo "Public route table associated"
    
    # Create a NAT gateway in the public subnet for outgoing traffic from the private network.
    echo -n "Creating NAT Gateway..."
    NAT_IP_ADDRESS=$(aws ec2 allocate-address --domain vpc --query AllocationId --output text)
    
    NAT_GATEWAY_ID=$(aws ec2 create-nat-gateway --subnet-id $PUBLIC_SUBNET_ID --allocation-id $NAT_IP_ADDRESS --query NatGateway.NatGatewayId --output text)
    
    aws ec2 create-tags --resources $NAT_IP_ADDRESS --resources $NAT_GATEWAY_ID --tags Key=Name,Value=$CLUSTER_NAME
    sleep 10
    echo "done."
    
    # Create a route table for the private subnet to the NAT gateway.
    echo -n "Creating a route table for the private subnet to the NAT gateway..."
    PRIVATE_ROUTE_TABLE_ID=$(aws ec2 create-route-table --vpc-id $VPC_ID --query RouteTable.RouteTableId --output text)
    
    aws ec2 create-tags --resources $PRIVATE_ROUTE_TABLE_ID $NAT_IP_ADDRESS --tags Key=Name,Value=$CLUSTER_NAME-private
    
    aws ec2 create-route --route-table-id $PRIVATE_ROUTE_TABLE_ID --destination-cidr-block 0.0.0.0/0 --gateway-id $NAT_GATEWAY_ID > /dev/null 2>&1
    
    aws ec2 associate-route-table --subnet-id $PRIVATE_SUBNET_ID --route-table-id $PRIVATE_ROUTE_TABLE_ID > /dev/null 2>&1
    
    echo "done."
    
    # echo "***********VARIABLE VALUES*********"
    # echo "VPC_ID="$VPC_ID
    # echo "PUBLIC_SUBNET_ID="$PUBLIC_SUBNET_ID
    # echo "PRIVATE_SUBNET_ID="$PRIVATE_SUBNET_ID
    # echo "PUBLIC_ROUTE_TABLE_ID="$PUBLIC_ROUTE_TABLE_ID
    # echo "PRIVATE_ROUTE_TABLE_ID="$PRIVATE_ROUTE_TABLE_ID
    # echo "NAT_GATEWAY_ID="$NAT_GATEWAY_ID
    # echo "IGW_ID="$IGW_ID
    # echo "NAT_IP_ADDRESS="$NAT_IP_ADDRESS
    
    echo "Setup complete."
    echo ""
    echo "To make the cluster create commands easier, please run the following commands to set the environment variables:"
    echo "export PUBLIC_SUBNET_ID=$PUBLIC_SUBNET_ID"
    echo "export PRIVATE_SUBNET_ID=$PRIVATE_SUBNET_ID"
    Copy to Clipboard Toggle word wrap
  3. 스크립트는 명령을 출력합니다. 나중에 사용할 서브넷 ID를 저장하려면 명령을 환경 변수로 설정합니다. 명령을 복사하고 실행합니다.

    $ export PUBLIC_SUBNET_ID=$PUBLIC_SUBNET_ID
    $ export PRIVATE_SUBNET_ID=$PRIVATE_SUBNET_ID
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 환경 변수를 확인합니다.

    $ echo "Public Subnet: $PUBLIC_SUBNET_ID"; echo "Private Subnet: $PRIVATE_SUBNET_ID"
    Copy to Clipboard Toggle word wrap

    출력 예

    Public Subnet: subnet-0faeeeb0000000000
    Private Subnet: subnet-011fe340000000000
    Copy to Clipboard Toggle word wrap

1.1.1.2. OIDC 구성 생성

이 워크샵에서는 OIDC 구성을 생성할 때 자동 모드를 사용합니다. 또한 나중에 사용할 수 있도록 OIDC ID를 환경 변수로 저장합니다. 명령은 ROSA CLI를 사용하여 클러스터의 고유한 OIDC 구성을 생성합니다.

  • 다음 명령을 실행하여 OIDC 구성을 생성합니다.

    $ export OIDC_ID=$(rosa create oidc-config --mode auto --managed --yes -o json | jq -r '.id')
    Copy to Clipboard Toggle word wrap

1.1.2. 추가 환경 변수 생성

  • 다음 명령을 실행하여 환경 변수를 설정합니다. 이러한 변수를 사용하면 명령을 실행하여 ROSA 클러스터를 더 쉽게 생성할 수 있습니다.

    $ export CLUSTER_NAME=<cluster_name>
    $ export REGION=<VPC_region>
    Copy to Clipboard Toggle word wrap
    작은 정보

    rosa whoami 를 실행하여 VPC 리전을 찾습니다.

1.1.3. 클러스터 생성

  1. 선택 사항: 다음 명령을 실행하여 Operator 정책 및 AWS IAM 역할 및 정책을 포함하여 계정 전체 역할 및 정책을 생성합니다.

    중요

    이 계정에 ROSA를 처음 배포하고 아직 계정 역할 및 정책을 생성하지 않은 경우에만 이 단계를 완료합니다.

    $ rosa create account-roles --mode auto --yes
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 클러스터를 생성합니다.

    $ rosa create cluster --cluster-name $CLUSTER_NAME \
    --subnet-ids ${PUBLIC_SUBNET_ID},${PRIVATE_SUBNET_ID} \
    --hosted-cp \
    --region $REGION \
    --oidc-config-id $OIDC_ID \
    --sts --mode auto --yes
    Copy to Clipboard Toggle word wrap

약 10분 후에 클러스터가 준비되었습니다. 클러스터에는 선택한 리전에서 세 개의 AWS 가용성 영역에 걸쳐 컨트롤 플레인이 있으며 AWS 계정에 두 개의 작업자 노드를 생성합니다.

1.1.4. 설치 상태 확인

  1. 다음 명령 중 하나를 실행하여 클러스터 상태를 확인합니다.

    • 클러스터 상태에 대한 자세한 보기를 보려면 다음을 실행합니다.

      $ rosa describe cluster --cluster $CLUSTER_NAME
      Copy to Clipboard Toggle word wrap
    • 클러스터 상태에 대한 abridged 뷰의 경우 다음을 실행합니다.

      $ rosa list clusters
      Copy to Clipboard Toggle word wrap
    • 로그가 진행 중인 것을 확인하려면 다음을 실행합니다.

      $ rosa logs install --cluster $CLUSTER_NAME --watch
      Copy to Clipboard Toggle word wrap
  2. 상태가 "준비"로 변경되면 클러스터가 설치됩니다. 작업자 노드가 온라인 상태가 되는 데 몇 분이 더 걸릴 수 있습니다.

1.2. 관리자 생성

관리(admin) 사용자를 생성하면 클러스터에 빠르게 액세스할 수 있습니다. 다음 단계에 따라 admin 사용자를 생성합니다.

참고

관리자는 이 튜토리얼 설정에서 잘 작동합니다. 실제 배포의 경우 공식 ID 공급자 를 사용하여 클러스터에 액세스하고 사용자에게 관리자 권한을 부여합니다.

  1. 다음 명령을 실행하여 admin 사용자를 생성합니다.

    rosa create admin --cluster=<cluster-name>
    Copy to Clipboard Toggle word wrap

    출력 예

    W: It is recommended to add an identity provider to login to this cluster. See 'rosa create idp --help' for more information.
    I: Admin account has been added to cluster 'my-rosa-cluster'. It may take up to a minute for the account to become active.
    I: To login, run the following command:
    oc login https://api.my-rosa-cluster.abcd.p1.openshiftapps.com:6443 \
    --username cluster-admin \
    --password FWGYL-2mkJI-00000-00000
    Copy to Clipboard Toggle word wrap

  2. 이전 단계에서 반환된 로그인 명령을 복사하여 터미널에 붙여넣습니다. 그러면 클러스터 사용을 시작할 수 있도록 CLI를 사용하여 클러스터에 로그인합니다.

    $ oc login https://api.my-rosa-cluster.abcd.p1.openshiftapps.com:6443 \
    >    --username cluster-admin \
    >    --password FWGYL-2mkJI-00000-00000
    Copy to Clipboard Toggle word wrap

    출력 예

    Login successful.
    
    You have access to 79 projects, the list has been suppressed. You can list all projects with ' projects'
    
    Using project "default".
    Copy to Clipboard Toggle word wrap

  3. admin 사용자로 로그인했는지 확인하려면 다음 명령 중 하나를 실행합니다.

    • 옵션 1:

      $ oc whoami
      Copy to Clipboard Toggle word wrap

      출력 예

      cluster-admin
      Copy to Clipboard Toggle word wrap

    • 옵션 2:

      oc get all -n openshift-apiserver
      Copy to Clipboard Toggle word wrap

      관리자만 오류 없이 이 명령을 실행할 수 있습니다.

  4. 이제 이 튜토리얼에 충분한 관리자 사용자로 클러스터를 사용할 수 있습니다. 실제 배포의 경우 다음 튜토리얼에서 설명하는 ID 공급자를 설정하는 것이 좋습니다.

1.3. ID 공급자 설정

클러스터에 로그인하려면 IDP(ID 공급자)를 설정합니다. 이 튜토리얼에서는 GitHub를 예제 IDP로 사용합니다. ROSA에서 지원하는 IDP의 전체 목록을 참조하십시오.

  • 모든 IDP 옵션을 보려면 다음 명령을 실행합니다.

    rosa create idp --help
    Copy to Clipboard Toggle word wrap

1.3.1. GitHub를 사용하여 IDP 설정

  1. GitHub 계정에 로그인합니다.
  2. 관리자인 새 GitHub 조직을 생성합니다.

    작은 정보

    기존 조직의 관리자이고 해당 조직을 사용하려는 경우 9 단계로 건너뜁니다.

    + 아이콘을 클릭한 다음 새 조직을 클릭합니다.

  3. 상황에 가장 적합한 계획을 선택하거나 무료로 조인을 클릭합니다.
  4. 조직 계정 이름, 이메일, 개인 또는 비즈니스 계정인지를 입력합니다. 그런 다음 다음을 클릭합니다.

  5. 선택 사항: 다른 사용자의 GitHub ID를 추가하여 ROSA 클러스터에 대한 추가 액세스 권한을 부여합니다. 나중에 추가할 수도 있습니다.
  6. 설정 완료 를 클릭합니다.
  7. 선택 사항: 다음 페이지에서 요청된 정보를 입력합니다.
  8. Submit 을 클릭합니다.
  9. 터미널로 돌아가서 다음 명령을 입력하여 GitHub IDP를 설정합니다.

    rosa create idp --cluster=<cluster name> --interactive
    Copy to Clipboard Toggle word wrap
  10. 다음 값을 입력합니다.

    Type of identity provider: github
    Identity Provider Name: <IDP-name>
    Restrict to members of: organizations
    GitHub organizations: <organization-account-name>
    Copy to Clipboard Toggle word wrap
  11. CLI에서 링크를 제공합니다. 링크를 복사하여 브라우저에 붙여넣고 Enter 키를 누릅니다. 그러면 OAuth에 이 애플리케이션을 등록하는 데 필요한 정보가 채워집니다. 정보를 수정할 필요가 없습니다.

  12. Register application을 클릭합니다.

  13. 다음 페이지에는 클라이언트 ID 가 표시됩니다. ID를 복사하여 클라이언트 ID 를 요청하는 터미널에 붙여넣습니다.

    참고

    탭을 닫지 마십시오.

  14. CLI에서 클라이언트 시크릿 을 요청합니다. 브라우저로 돌아가서 새 클라이언트 시크릿 생성 을 클릭합니다.

  15. 사용자를 위해 보안이 생성됩니다. 시크릿은 다시 표시되지 않으므로 복사하십시오.
  16. 시크릿을 터미널에 붙여넣고 Enter 를 누릅니다.
  17. GitHub Enterprise 호스트 이름을 비워 둡니다.
  18. 클레임을 선택합니다.
  19. IDP가 생성되고 구성이 클러스터에 배치될 때까지 약 1분 정도 기다립니다.

  20. 반환된 링크를 복사하여 브라우저에 붙여넣습니다. 새 IDP는 선택한 이름으로 사용할 수 있어야 합니다. IDP를 클릭하고 GitHub 인증 정보를 사용하여 클러스터에 액세스합니다.

1.3.2. 다른 사용자에게 클러스터에 대한 액세스 권한 부여

다른 클러스터 사용자에게 액세스 권한을 부여하려면 이 클러스터에 사용되는 GitHub 조직에 GitHub 사용자 ID를 추가해야 합니다.

  1. GitHub에서 조직 페이지로 이동합니다.
  2. 프로필 아이콘을 클릭한 다음 조직을 클릭합니다. 그런 다음 &lt ;your-organization-name>을 클릭합니다. 이 예에서는 my-rosa-cluster 입니다.

  3. 담당자 초대를 클릭합니다.

  4. 새 사용자의 GitHub ID를 입력하고 올바른 사용자를 선택한 다음 Invite 를 클릭합니다.
  5. 새 사용자가 초대를 수락하면 하이브리드 클라우드 콘솔 링크와 GitHub 자격 증명을 사용하여 ROSA 클러스터에 로그인할 수 있습니다.

1.4. 관리자 권한 부여

관리(관리자) 권한은 클러스터에 추가한 사용자에게 자동으로 부여되지 않습니다. 특정 사용자에게 관리자 수준 권한을 부여하려면 각 사용자에게 수동으로 권한을 부여해야 합니다. ROSA CLI(명령줄 인터페이스) 또는 Red Hat OpenShift Cluster Manager 웹 UI(사용자 인터페이스)에서 관리자 권한을 부여할 수 있습니다.

Red Hat은 다음 두 가지 유형의 관리자 권한을 제공합니다.

  • cluster-admin:cluster-admin 권한은 admin 사용자에게 클러스터 내에서 전체 권한을 부여합니다.
  • dedicated-admin:dedicated-admin 권한을 사용하면 관리자가 클러스터 손상을 방지하기 위해 특정 제한 사항을 사용하여 대부분의 관리 작업을 완료할 수 있습니다. 승격된 권한이 필요한 경우 dedicated-admin 을 사용하는 것이 좋습니다.

관리자 권한에 대한 자세한 내용은 클러스터 관리 설명서를 참조하십시오.

1.4.1. ROSA CLI 사용

  1. 클러스터를 생성한 사용자라고 가정하면 다음 명령 중 하나를 실행하여 관리자 권한을 부여합니다.

    • cluster-admin 의 경우:

      $ rosa grant user cluster-admin --user <idp_user_name> --cluster=<cluster-name>
      Copy to Clipboard Toggle word wrap
    • dedicated-admin 의 경우 :

      $ rosa grant user dedicated-admin --user <idp_user_name> --cluster=<cluster-name>
      Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 관리자 권한이 추가되었는지 확인합니다.

    $ rosa list users --cluster=<cluster-name>
    Copy to Clipboard Toggle word wrap

    출력 예

    $ rosa list users --cluster=my-rosa-cluster
    ID                 GROUPS
    <idp_user_name>    cluster-admins
    Copy to Clipboard Toggle word wrap

  3. 현재 Red Hat Hybrid Cloud Console에 로그인한 경우 콘솔에서 로그아웃하고 클러스터에 다시 로그인하여 "관리자 패널"에 새로운 관점을 확인합니다. incognito 또는 private 창이 필요할 수 있습니다.

    cloud experts getting started admin rights admin panel

  4. 다음 명령을 실행하여 관리자 권한이 계정에 추가되었는지 테스트할 수도 있습니다. cluster-admin 사용자만 오류 없이 이 명령을 실행할 수 있습니다.

    $ oc get all -n openshift-apiserver
    Copy to Clipboard Toggle word wrap

1.4.2. Red Hat OpenShift Cluster Manager UI 사용

  1. OpenShift Cluster Manager 에 로그인합니다.
  2. 클러스터를 선택합니다.
  3. 액세스 제어 탭을 클릭합니다.
  4. 사이드바에서 클러스터 역할 및 액세스 탭을 클릭합니다.
  5. 사용자 추가를 클릭합니다.

  6. 팝업 화면에서 사용자 ID를 입력합니다.
  7. cluster-admins 또는 dedicated-admins 권한을 부여할지 여부를 선택합니다.

1.5. 클러스터에 액세스

CLI(명령줄 인터페이스) 또는 Red Hat Hybrid Cloud Console 사용자 인터페이스(UI)를 사용하여 클러스터에 연결할 수 있습니다.

1.5.1. CLI를 사용하여 클러스터에 액세스

CLI를 사용하여 클러스터에 액세스하려면 oc CLI가 설치되어 있어야 합니다. 튜토리얼을 따르는 경우 oc CLI를 이미 설치했습니다.

  1. OpenShift Cluster Manager 에 로그인합니다.
  2. 오른쪽 상단에 있는 사용자 이름을 클릭합니다.
  3. 로그인 명령 복사를 클릭합니다.

  4. 그러면 선택한 IDP(ID 공급자)가 포함된 새 탭이 열립니다. 사용할 IDP를 클릭합니다. 예를 들면 "rosa-github"입니다.

  5. 새 탭이 열립니다. 토큰 표시를 클릭합니다.
  6. 터미널에서 다음 명령을 실행합니다.

    $ oc login --token=sha256~GBAfS4JQ0t1UTKYHbWAK6OUWGUkdMGz000000000000 --server=https://api.my-rosa-cluster.abcd.p1.openshiftapps.com:6443
    Copy to Clipboard Toggle word wrap

    출력 예

    Logged into "https://api.my-rosa-cluster.abcd.p1.openshiftapps.com:6443" as "rosa-user" using the token provided.
    
    You have access to 79 projects, the list has been suppressed. You can list all projects with ' projects'
    
    Using project "default".
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 실행하여 로그인했는지 확인합니다.

    $ oc whoami
    Copy to Clipboard Toggle word wrap

    출력 예

    rosa-user
    Copy to Clipboard Toggle word wrap

  8. 이제 클러스터에 액세스할 수 있습니다.

1.5.2. 하이브리드 클라우드 콘솔을 통해 클러스터에 액세스

  1. OpenShift Cluster Manager 에 로그인합니다.

    1. 하이브리드 클라우드 콘솔 URL을 검색하려면 다음을 실행합니다.

      rosa describe cluster -c <cluster-name> | grep Console
      Copy to Clipboard Toggle word wrap
  2. IDP를 클릭합니다. 예를 들면 "rosa-github"입니다.

  3. 사용자 자격 증명을 입력합니다.
  4. 로그인해야 합니다. 튜토리얼을 따르는 경우 cluster-admin이 되고 관리자 패널이 표시되는 Hybrid Cloud Console 웹 페이지가 표시되어야 합니다.

1.6. 작업자 노드 관리

ROSA(Red Hat OpenShift Service on AWS)에서는 머신 풀을 사용하여 작업자 노드의 측면을 변경합니다. 시스템 풀을 사용하면 여러 시스템을 단일 엔터티로 관리할 수 있습니다. 모든 ROSA 클러스터에는 클러스터를 생성할 때 생성되는 기본 머신 풀이 있습니다. 자세한 내용은 머신 풀 설명서를 참조하십시오.

1.6.1. 머신 풀 생성

CLI(명령줄 인터페이스) 또는 UI(사용자 인터페이스)를 사용하여 머신 풀을 생성할 수 있습니다.

1.6.1.1. CLI를 사용하여 머신 풀 생성
  1. 다음 명령을 실행합니다.

    $ rosa create machinepool --cluster=<cluster-name> --name=<machinepool-name> --replicas=<number-nodes>
    Copy to Clipboard Toggle word wrap

    입력 예

     $ rosa create machinepool --cluster=my-rosa-cluster --name=new-mp
     --replicas=2
    Copy to Clipboard Toggle word wrap

    출력 예

    I: Machine pool 'new-mp' created successfully on cluster 'my-rosa-cluster'
    I: To view all machine pools, run 'rosa list machinepools -c my-rosa-cluster'
    Copy to Clipboard Toggle word wrap

  2. 선택 사항: 다음 명령을 실행하여 새 머신 풀의 특정 노드에 노드 레이블 또는 테인트를 추가합니다.

    rosa create machinepool --cluster=<cluster-name> --name=<machinepool-name> --replicas=<number-nodes> --labels=`<key=pair>`
    Copy to Clipboard Toggle word wrap

    입력 예

    $ rosa create machinepool --cluster=my-rosa-cluster --name=db-nodes-mp --replicas=2 --labels='app=db','tier=backend'
    Copy to Clipboard Toggle word wrap

    출력 예

    I: Machine pool 'db-nodes-mp' created successfully on cluster 'my-rosa-cluster'
    Copy to Clipboard Toggle word wrap

    이렇게 하면 하나의 단위로 관리할 수 있는 추가 2개의 노드가 생성되고 표시된 레이블을 할당합니다.

  3. 다음 명령을 실행하여 머신 풀 생성 및 할당된 라벨을 확인합니다.

    rosa list machinepools --cluster=<cluster-name>
    Copy to Clipboard Toggle word wrap

    출력 예

    ID       AUTOSCALING  REPLICAS  INSTANCE TYPE  LABELS    TAINTS    AVAILABILITY ZONE  SUBNET                    DISK SIZE  VERSION  AUTOREPAIR
    workers  Yes          2/2-4     m5.xlarge                          us-east-1f         subnet-<subnet_id>  300 GiB    4.14.36  Yes
    Copy to Clipboard Toggle word wrap

1.6.1.2. UI를 사용하여 머신 풀 생성
  1. OpenShift Cluster Manager 에 로그인하고 클러스터를 클릭합니다.

  2. 머신 풀 탭을 클릭합니다.

    cloud experts getting started managing mp ocm

  3. 머신 풀 추가를 클릭합니다.
  4. 원하는 구성을 입력합니다.

    작은 정보

    노드 레이블 및 테인트 섹션을 확장하여 머신 풀의 노드에 노드 레이블 및 테인트를 추가할 수도 있습니다.

  5. 시스템 풀 추가 버튼을 클릭하여 저장합니다.
  6. 생성한 새 머신 풀이 표시됩니다.

1.6.2. 작업자 노드 스케일링

머신 풀을 편집하여 해당 특정 머신 풀의 작업자 노드 수를 확장합니다. CLI 또는 UI를 사용하여 작업자 노드를 확장할 수 있습니다.

1.6.2.1. CLI를 사용하여 작업자 노드 스케일링
  1. 다음 명령을 실행하여 각 클러스터와 함께 생성된 기본 머신 풀을 확인합니다.

    rosa list machinepools --cluster=<cluster-name>
    Copy to Clipboard Toggle word wrap

    출력 예

    ID          AUTOSCALING  REPLICAS  INSTANCE TYPE  LABELS            TAINTS    AVAILABILITY ZONES
    Default     No           2         m5.xlarge                                  us-east-1a
    Copy to Clipboard Toggle word wrap

  2. 기본 머신 풀을 다른 수의 노드로 확장하려면 다음 명령을 실행합니다.

    rosa edit machinepool --cluster=<cluster-name> --replicas=<number-nodes> <machinepool-name>
    Copy to Clipboard Toggle word wrap

    입력 예

    rosa edit machinepool --cluster=my-rosa-cluster --replicas 3 Default
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 시스템 풀이 확장되었는지 확인합니다.

    rosa describe cluster --cluster=<cluster-name> | grep Compute
    Copy to Clipboard Toggle word wrap

    입력 예

    $ rosa describe cluster --cluster=my-rosa-cluster | grep Compute
    Copy to Clipboard Toggle word wrap

    출력 예

     - Compute (Autoscaled):    2-4
     - Compute (current):       2
    Copy to Clipboard Toggle word wrap

1.6.2.2. UI를 사용하여 작업자 노드 스케일링
  1. 편집할 머신 풀 오른쪽에 있는 세 개의 점을 클릭합니다.
  2. 편집을 클릭합니다.
  3. 원하는 수의 노드를 입력하고 저장을 클릭합니다.
  4. 클러스터를 선택하고 개요 탭을 클릭하고 Compute 목록으로 스크롤하여 클러스터가 확장되었는지 확인합니다. 컴퓨팅 목록은 확장된 노드와 같아야 합니다. 예: 3/3입니다.

1.6.2.3. 노드 라벨 추가
  1. 다음 명령을 사용하여 노드 레이블을 추가합니다.

    rosa edit machinepool --cluster=<cluster-name> --replicas=<number-nodes> --labels='key=value' <machinepool-name>
    Copy to Clipboard Toggle word wrap

    입력 예

    rosa edit machinepool --cluster=my-rosa-cluster --replicas=2 --labels 'foo=bar','baz=one' new-mp
    Copy to Clipboard Toggle word wrap

    새 머신 풀에 레이블을 2개 추가합니다.

중요

이 명령은 모든 시스템 풀 구성을 새로 정의된 구성으로 교체합니다. 다른 레이블을 추가하고 이전 레이블을 유지하려면 새 레이블과 기존 레이블을 모두 지정해야 합니다. 그렇지 않으면 명령은 기존의 모든 레이블을 추가하려는 레이블로 교체합니다. 마찬가지로 레이블을 삭제하려면 삭제하려는 명령을 제외하고 명령을 실행하고 원하는 상태를 표시합니다.

1.6.3. 노드 유형 혼합

새 머신 풀을 사용하여 동일한 클러스터에서 다른 작업자 노드 머신 유형을 혼합할 수도 있습니다. 생성된 후에는 머신 풀의 노드 유형을 변경할 수 없지만 --instance-type 플래그를 추가하여 다른 노드로 새 머신 풀을 생성할 수 있습니다.

  1. 예를 들어 데이터베이스 노드를 다른 노드 유형으로 변경하려면 다음 명령을 실행합니다.

    rosa create machinepool --cluster=<cluster-name> --name=<mp-name> --replicas=<number-nodes> --labels='<key=pair>' --instance-type=<type>
    Copy to Clipboard Toggle word wrap

    입력 예

    rosa create machinepool --cluster=my-rosa-cluster --name=db-nodes-large-mp --replicas=2 --labels='app=db','tier=backend' --instance-type=m5.2xlarge
    Copy to Clipboard Toggle word wrap

  2. 사용 가능한 모든 인스턴스 유형을 보려면 다음 명령을 실행합니다.

    rosa list instance-types
    Copy to Clipboard Toggle word wrap
  3. 단계별 변경을 수행하려면 --interactive 플래그를 사용합니다.

    rosa create machinepool -c <cluster-name> --interactive
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 머신 풀을 나열하고 새로운 대규모 인스턴스 유형을 확인합니다.

    rosa list machinepools -c <cluster-name>
    Copy to Clipboard Toggle word wrap

1.7. 자동 확장

클러스터 자동 스케일러 는 Pod 리소스를 기반으로 클러스터에서 작업자 노드를 추가하거나 제거합니다.

클러스터 자동 스케일러는 다음과 같은 경우 클러스터 크기를 늘립니다.

  • 리소스가 부족하여 Pod가 현재 노드에서 예약되지 않습니다.
  • 배포 요구 사항을 충족하기 위해 다른 노드가 필요합니다.

클러스터 자동 스케일러는 사용자가 지정한 제한을 초과하여 클러스터 리소스를 늘리지 않습니다.

클러스터 자동 스케일러는 다음과 같은 경우 클러스터 크기를 줄입니다.

  • 일부 노드는 상당한 기간 동안 지속적으로 필요하지 않습니다. 예를 들어 노드에 리소스 사용량이 부족하고 중요한 모든 Pod가 다른 노드에 적합할 수 있는 경우입니다.

1.7.1. CLI를 사용하여 기존 머신 풀에 대한 자동 스케일링 활성화

참고

클러스터 생성 시 및 --enable-autoscaling 옵션을 사용하여 새 머신 풀을 생성할 때 클러스터 자동 스케일링을 활성화할 수 있습니다.

  1. 자동 스케일링은 머신 풀 가용성에 따라 설정됩니다. 자동 스케일링에 사용할 수 있는 머신 풀을 확인하려면 다음 명령을 실행합니다.

    $ rosa list machinepools -c <cluster-name>
    Copy to Clipboard Toggle word wrap

    출력 예

    ID       AUTOSCALING  REPLICAS  INSTANCE TYPE  LABELS    TAINTS    AVAILABILITY ZONE  SUBNET                    DISK SIZE  VERSION  AUTOREPAIR
    workers  No           2/2       m5.xlarge                          us-east-1f         subnet-<subnet_id>  300 GiB    4.14.36  Yes
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 사용 가능한 머신 풀에 자동 스케일링을 추가합니다.

    $ rosa edit machinepool -c <cluster-name> --enable-autoscaling <machinepool-name> --min-replicas=<num> --max-replicas=<num>
    Copy to Clipboard Toggle word wrap

    입력 예

    $ rosa edit machinepool -c my-rosa-cluster --enable-autoscaling workers --min-replicas=2 --max-replicas=4
    Copy to Clipboard Toggle word wrap

    위의 명령은 리소스에 따라 2~4개의 노드 사이를 확장하는 작업자 노드에 대한 자동 스케일러를 생성합니다.

1.7.2. UI를 사용하여 기존 머신 풀에 대한 자동 스케일링 활성화

참고

머신 풀을 생성할 때 자동 스케일링 활성화 확인란을 선택하여 클러스터 생성 시 클러스터 자동 스케일링을 활성화할 수 있습니다.

  1. 머신 풀 탭으로 이동하여 오른쪽에 있는 세 개의 점을 클릭합니다.
  2. 편집을 클릭한 다음 자동 스케일링을 활성화합니다.
  3. 최소 및 최대 노드 수를 편집하거나 기본 수를 남겨 둡니다.
  4. 저장을 클릭합니다.
  5. 다음 명령을 실행하여 자동 스케일링이 추가되었는지 확인합니다.

    $ rosa list machinepools -c <cluster-name>
    Copy to Clipboard Toggle word wrap

    출력 예

    ID       AUTOSCALING  REPLICAS  INSTANCE TYPE  LABELS    TAINTS    AVAILABILITY ZONE  SUBNET                    DISK SIZE  VERSION  AUTOREPAIR
    workers  Yes          2/2-4     m5.xlarge                          us-east-1f         subnet-<subnet_id>  300 GiB    4.14.36  Yes
    Copy to Clipboard Toggle word wrap

1.8. 클러스터 업그레이드

ROSA(Red Hat OpenShift Service on AWS)는 관리형 서비스의 일부로 모든 클러스터 업그레이드를 실행합니다. 명령을 실행하거나 클러스터를 변경할 필요가 없습니다. 편리한 시간에 업그레이드를 예약할 수 있습니다.

클러스터 업그레이드 예약 방법은 다음과 같습니다.

  • 수동으로 CLI(명령줄 인터페이스) 사용: 즉시 업그레이드하거나 향후 날짜 및 시간에 대해 일회성 업그레이드를 예약합니다.
  • Red Hat OpenShift Cluster Manager 사용자 인터페이스(UI)를 수동으로 사용: 즉시 업그레이드하거나 향후 날짜 및 시간에 대해 일회성 업그레이드를 예약합니다.
  • 자동화된 업그레이드: 수동으로 예약하지 않고도 새 버전을 사용할 수 있을 때마다 반복적인 y-stream 업그레이드에 대한 업그레이드 창을 설정합니다. 마이너 버전은 수동으로 예약해야 합니다.

클러스터 업그레이드에 대한 자세한 내용은 다음 명령을 실행합니다.

$ rosa upgrade cluster --help
Copy to Clipboard Toggle word wrap

1.8.1. CLI를 사용하여 클러스터 수동 업그레이드

  1. 다음 명령을 실행하여 업그레이드할 수 있는 업그레이드가 있는지 확인합니다.

    $ rosa list upgrade -c <cluster-name>
    Copy to Clipboard Toggle word wrap

    출력 예

    $ rosa list upgrade -c <cluster-name>
    VERSION  NOTES
    4.14.7   recommended
    4.14.6
    ...
    Copy to Clipboard Toggle word wrap

    위의 예에서 4.14.7 및 4.14.6 버전을 모두 사용할 수 있습니다.

  2. 다음 명령을 실행하여 1시간 이내에 업그레이드할 클러스터를 예약합니다.

    $ rosa upgrade cluster -c --control-plane <cluster-name> --version <desired-version>
    Copy to Clipboard Toggle word wrap
  3. 선택 사항: 다음 명령을 실행하여 나중에 업그레이드하도록 클러스터를 예약합니다.

    $ rosa upgrade cluster -c <cluster-name> --version <desired-version> --schedule-date <future-date-for-update> --schedule-time <future-time-for-update>
    Copy to Clipboard Toggle word wrap

1.8.2. UI를 사용하여 클러스터 수동 업그레이드

  1. OpenShift Cluster Manager에 로그인하고 업그레이드할 클러스터를 선택합니다.
  2. 설정 탭을 클릭합니다.
  3. 업그레이드할 수 있는 경우 업데이트를 클릭합니다.

  4. 새 창에서 업그레이드할 버전을 선택합니다.
  5. 업그레이드 시간을 예약하거나 즉시 시작합니다.

1.8.3. 자동 반복 업그레이드 설정

  1. OpenShift Cluster Manager에 로그인하고 업그레이드할 클러스터를 선택합니다.
  2. 설정 탭을 클릭합니다.

    1. 업데이트 전략에서 업데이트 반복 을 클릭합니다.
  3. 업그레이드 날짜 및 시간을 설정합니다.
  4. 저장을 클릭합니다.

1.9. 클러스터 삭제

CLI(명령줄 인터페이스) 또는 UI(사용자 인터페이스)를 사용하여 AWS(ROSA)에서 Red Hat OpenShift Service를 삭제할 수 있습니다.

1.9.1. CLI를 사용하여 ROSA 클러스터 삭제

  1. 선택 사항: 다음 명령을 실행하여 올바른 클러스터를 삭제하도록 클러스터를 나열합니다.

    $ rosa list clusters
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 클러스터를 삭제합니다.

    $ rosa delete cluster --cluster <cluster-name>
    Copy to Clipboard Toggle word wrap
    주의

    이 명령은 복구할 수 없습니다.

  3. CLI에서 클러스터를 삭제할지 묻는 메시지를 표시합니다. y 를 누른 다음 Enter 를 누릅니다. 클러스터 및 관련 인프라가 모두 삭제됩니다.

    참고

    모든 AWS STS 및 IAM 역할 및 정책은 다음 단계에 따라 클러스터 삭제가 완료되면 수동으로 삭제해야 합니다.

  4. CLI는 생성된 OpenID Connect(OIDC) 공급자 및 Operator IAM 역할 리소스를 삭제하는 명령을 출력합니다. 이러한 리소스를 삭제하기 전에 클러스터가 삭제를 완료할 때까지 기다립니다. 다음 명령을 실행하여 빠른 상태 점검을 수행합니다.

    $ rosa list clusters
    Copy to Clipboard Toggle word wrap
  5. 클러스터가 삭제되면 다음 명령을 실행하여 OIDC 공급자를 삭제합니다.

    $ rosa delete oidc-provider -c <clusterID> --mode auto --yes
    Copy to Clipboard Toggle word wrap
  6. 다음 명령을 실행하여 Operator IAM 역할을 삭제합니다.

    $ rosa delete operator-roles -c <clusterID> --mode auto --yes
    Copy to Clipboard Toggle word wrap
    참고

    이 명령에는 클러스터 이름이 아닌 클러스터 ID가 필요합니다.

  7. 동일한 계정의 다른 클러스터에 더 이상 필요하지 않은 경우에만 나머지 계정 역할을 제거합니다. 이 계정에 다른 ROSA 클러스터를 만들려면 이 단계를 수행하지 마십시오.

    계정 역할을 삭제하려면 해당 역할을 생성할 때 사용되는 접두사를 알아야 합니다. 달리 지정하지 않는 한 기본값은 "ManagedOpenShift"입니다.

    다음 명령을 실행하여 계정 역할을 삭제합니다.

    $ rosa delete account-roles --prefix <prefix> --mode auto --yes
    Copy to Clipboard Toggle word wrap

1.9.2. UI를 사용하여 ROSA 클러스터 삭제

  1. OpenShift Cluster Manager 에 로그인하고 삭제할 클러스터를 찾습니다.
  2. 클러스터 오른쪽에 있는 점 세 개를 클릭합니다.

  3. 드롭다운 메뉴에서 클러스터 삭제 를 클릭합니다.

  4. 삭제를 확인할 클러스터 이름을 입력하고 삭제를 클릭합니다.

1.10. 지원 받기

필요한 경우 올바른 도움말을 찾는 것이 중요합니다. 이는 도움이 필요할 때 필요한 리소스 중 일부입니다.

1.10.1. 지원 연락처 추가

클러스터에 대한 통신을 위해 추가 이메일 주소를 추가할 수 있습니다.

  1. Red Hat OpenShift Cluster Manager UI(사용자 인터페이스)의 사이드 탐색 탭에서 Cluster List 를 클릭합니다.
  2. 지원이 필요한 클러스터를 선택합니다.
  3. 지원 탭을 클릭합니다.
  4. 알림 연락처 추가 를 클릭하고 추가 이메일 주소를 입력합니다.

1.10.2. UI를 사용한 지원을 위해 Red Hat에 문의

  1. OpenShift Cluster Manager UI에서 지원 탭을 클릭합니다.
  2. 지원 케이스 열기를 클릭합니다.

1.10.3. 지원 페이지를 사용하여 Red Hat에 문의하십시오.

  1. Red Hat 지원 페이지로 이동합니다.
  2. 새 케이스 열기를 클릭합니다.

  3. Red Hat 계정에 로그인합니다.
  4. 지원에 문의하는 이유를 선택합니다.

  5. AWS의 Red Hat OpenShift Service를 선택합니다.

  6. 계속 을 클릭합니다.
  7. 문제에 대한 요약과 요청 세부 정보를 입력합니다. 파일, 로그 및 스크린샷을 업로드합니다. 자세한 내용은 Red Hat 지원이 도움이 될 수 있습니다.

    참고

    문제에 도움이 될 수 있는 관련 제안 사항이 이 페이지 하단에 표시됩니다.

  8. Continue 를 클릭합니다.
  9. 새 필드의 질문에 대답합니다.
  10. Continue 를 클릭합니다.
  11. 케이스에 대한 다음 정보를 입력합니다.

    1. 지원 수준: 프리미엄
    2. 심각도: Red Hat 지원 심각도 수준 정의를 검토하여 올바른 버전을 선택합니다.
    3. 그룹: 다른 몇 가지 케이스와 관련된 경우 해당 그룹을 선택할 수 있습니다.
    4. 언어
    5. 알림 보내기: 추가 이메일 주소를 추가하여 활동에 대한 알림을 유지합니다.
    6. Red Hat 동료: Red Hat의 모든 사용자와 협력하여 이를 루프에 유지하려면 여기에서 이메일 주소를 입력할 수 있습니다.
    7. 대체 케이스 ID: 고유한 ID를 첨부하려면 여기에서 입력할 수 있습니다.
  12. Continue 를 클릭합니다.
  13. 검토 화면에서 지원에 문의할 올바른 클러스터 ID를 선택해야 합니다.

  14. Submit 을 클릭합니다.
  15. 표시된 심각도 수준에 대해 커밋된 응답 시간을 기반으로 연락을 취할 것입니다.

2장. 애플리케이션 워크샵 배포

2.1. 워크샵 개요

2.1.1. 소개

클러스터를 프로비저닝한 후 이 워크샵에 따라 애플리케이션을 배포하여 컨테이너 기반 애플리케이션 배포 및 운영의 개념을 파악합니다.

워크샵 목표

  • S2I(Source-to-Image) 및 Kubernetes 배포 오브젝트를 사용하여 Node.js 기반 애플리케이션 배포
  • 소스 코드 변경 사항을 자동으로 푸시하도록 CD(Continuous Delivery) 파이프라인 설정
  • 자동 복구 애플리케이션 경험
  • ConfigMaps, 보안 및 환경 변수를 통해 구성 관리 살펴보기
  • 영구 스토리지를 사용하여 Pod를 다시 시작할 때마다 데이터 공유
  • Kubernetes 및 애플리케이션의 네트워킹 살펴보기
  • ROSA 및 Kubernetes 기능에 대해 숙지
  • Horizontal Pod Autoscaler(HPA)에서 로드를 기반으로 Pod 자동 스케일링

사전 요구 사항

2.1.2. OSToy 애플리케이션 정보

OSToy는 Kubernetes의 기능을 탐색할 수 있도록 ROSA 클러스터에 배포하는 Node.js 애플리케이션입니다.

이 애플리케이션에는 다음을 수행할 수 있는 사용자 인터페이스가 있습니다.

  • 로그에 메시지 쓰기 (stdout / stderr)
  • 자동 복구 보기를 위해 의도적으로 애플리케이션 충돌
  • 활성 상태 프로브 전환 및 OpenShift 동작 모니터링
  • ConfigMaps, 보안 및 환경 변수 읽기
  • 공유 스토리지에 연결된 경우 파일 읽기 및 쓰기
  • 포함된 마이크로 서비스를 사용하여 네트워크 연결, 클러스터 내 DNS 및 intra-communication 확인
  • HPA를 사용하여 Pod 자동 스케일링을 보려면 로드를 늘립니다.
2.1.2.1. OSToy 애플리케이션 다이어그램
2.1.2.2. OSToy UI 이해
  1. Pod 이름
  2. 홈: 애플리케이션 홈 페이지
  3. 영구 스토리지: 애플리케이션에 바인딩된 영구 볼륨에 데이터를 씁니다.
  4. 구성 맵: 애플리케이션 및 키:값 쌍에서 사용할 수 있는 ConfigMap을 표시합니다.
  5. 보안: 애플리케이션과 키:값 쌍에서 사용할 수 있는 시크릿을 표시합니다.
  6. ENV 변수: 애플리케이션에서 사용할 수 있는 환경 변수를 표시합니다.
  7. 네트워킹: 네트워킹 툴
  8. Pod 자동 확장: Pod 로드를 늘리고 HPA(horizontal Pod Autoscaler) 테스트
  9. ACK S3: 버킷에 오브젝트를 읽고 쓰기 위해 AWS S3와 통합
  10. 정보: 애플리케이션 정보
2.1.2.3. 랩 리소스
  • OSToy 애플리케이션 소스 코드
  • OSToy 프론트 엔드 컨테이너 이미지
  • OSToy 마이크로 서비스 컨테이너 이미지
  • 배포 정의 YAML 파일:

    ostoy-frontend-deployment.yaml

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: ostoy-pvc
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ostoy-frontend
      labels:
        app: ostoy
    spec:
      selector:
        matchLabels:
          app: ostoy-frontend
      strategy:
        type: Recreate
      replicas: 1
      template:
        metadata:
          labels:
            app: ostoy-frontend
        spec:
          # Uncomment to use with ACK portion of the workshop
          # If you chose a different service account name please replace it.
          # serviceAccount: ostoy-sa
          containers:
          - name: ostoy-frontend
            securityContext:
              allowPrivilegeEscalation: false
              runAsNonRoot: true
              seccompProfile:
                type: RuntimeDefault
              capabilities:
                drop:
                - ALL
            image: quay.io/ostoylab/ostoy-frontend:1.6.0
            imagePullPolicy: IfNotPresent
            ports:
            - name: ostoy-port
              containerPort: 8080
            resources:
              requests:
                memory: "256Mi"
                cpu: "100m"
              limits:
                memory: "512Mi"
                cpu: "200m"
            volumeMounts:
            - name: configvol
              mountPath: /var/config
            - name: secretvol
              mountPath: /var/secret
            - name: datavol
              mountPath: /var/demo_files
            livenessProbe:
              httpGet:
                path: /health
                port: 8080
              initialDelaySeconds: 10
              periodSeconds: 5
            env:
            - name: ENV_TOY_SECRET
              valueFrom:
                secretKeyRef:
                  name: ostoy-secret-env
                  key: ENV_TOY_SECRET
            - name: MICROSERVICE_NAME
              value: OSTOY_MICROSERVICE_SVC
            - name: NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          volumes:
            - name: configvol
              configMap:
                name: ostoy-configmap-files
            - name: secretvol
              secret:
                defaultMode: 420
                secretName: ostoy-secret
            - name: datavol
              persistentVolumeClaim:
                claimName: ostoy-pvc
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: ostoy-frontend-svc
      labels:
        app: ostoy-frontend
    spec:
      type: ClusterIP
      ports:
        - port: 8080
          targetPort: ostoy-port
          protocol: TCP
          name: ostoy
      selector:
        app: ostoy-frontend
    ---
    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      name: ostoy-route
    spec:
      to:
        kind: Service
        name: ostoy-frontend-svc
    ---
    apiVersion: v1
    kind: Secret
    metadata:
      name: ostoy-secret-env
    type: Opaque
    data:
      ENV_TOY_SECRET: VGhpcyBpcyBhIHRlc3Q=
    ---
    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: ostoy-configmap-files
    data:
      config.json:  '{ "default": "123" }'
    ---
    apiVersion: v1
    kind: Secret
    metadata:
      name: ostoy-secret
    data:
      secret.txt: VVNFUk5BTUU9bXlfdXNlcgpQQVNTV09SRD1AT3RCbCVYQXAhIzYzMlk1RndDQE1UUWsKU01UUD1sb2NhbGhvc3QKU01UUF9QT1JUPTI1
    type: Opaque
    Copy to Clipboard Toggle word wrap

    ostoy-microservice-deployment.yaml

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ostoy-microservice
      labels:
        app: ostoy
    spec:
      selector:
        matchLabels:
          app: ostoy-microservice
      replicas: 1
      template:
        metadata:
          labels:
            app: ostoy-microservice
        spec:
          containers:
          - name: ostoy-microservice
            securityContext:
              allowPrivilegeEscalation: false
              runAsNonRoot: true
              seccompProfile:
                type: RuntimeDefault
              capabilities:
                drop:
                - ALL
            image: quay.io/ostoylab/ostoy-microservice:1.5.0
            imagePullPolicy: IfNotPresent
            ports:
            - containerPort: 8080
              protocol: TCP
            resources:
              requests:
                memory: "128Mi"
                cpu: "50m"
              limits:
                memory: "256Mi"
                cpu: "100m"
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: ostoy-microservice-svc
      labels:
        app: ostoy-microservice
    spec:
      type: ClusterIP
      ports:
        - port: 8080
          targetPort: 8080
          protocol: TCP
      selector:
        app: ostoy-microservice
    Copy to Clipboard Toggle word wrap

  • ACK S3용 S3 버킷 매니페스트

    s3-bucket.yaml

    apiVersion: s3.services.k8s.aws/v1alpha1
    kind: Bucket
    metadata:
      name: ostoy-bucket
      namespace: ostoy
    spec:
      name: ostoy-bucket
    Copy to Clipboard Toggle word wrap

참고

OSToy 애플리케이션의 배포를 단순화하기 위해 위의 배포 매니페스트에 필요한 모든 오브젝트가 함께 그룹화됩니다. 일반적인 엔터프라이즈 배포에는 각 Kubernetes 오브젝트에 대한 별도의 매니페스트 파일이 권장됩니다.

2.2. Kubernetes를 사용하여 OSToy 애플리케이션 배포

애플리케이션을 배포하려면 컨테이너 이미지를 생성하고, 이미지 리포지토리에 저장하고, 해당 이미지를 사용하는 Deployment 오브젝트를 정의해야 합니다.

애플리케이션을 배포하려면 다음 단계를 수행해야 합니다.

  • 프런트 엔드 및 백엔드 마이크로 서비스 컨테이너의 이미지를 만듭니다.
  • 이미지 리포지토리에 컨테이너 이미지 저장
  • 애플리케이션에 대한 Kubernetes Deployment 오브젝트 생성
  • 애플리케이션 배포
참고

이 워크샵에서는 애플리케이션 배포에 중점을 두고 있으며 사용자가 기존 이미지를 사용하는 원격 파일을 실행합니다.

2.2.1. 로그인 명령 검색

프로세스

  1. 다음 명령을 실행하여 CLI(명령줄 인터페이스)에 로그인했는지 확인합니다.

    rosa whoami
    Copy to Clipboard Toggle word wrap

    명령줄 인터페이스에 로그인한 경우 "새 프로젝트 생성"으로 건너뜁니다. 명령줄 인터페이스에 로그인하지 않은 경우 이 절차를 계속합니다.

  2. 웹 콘솔을 사용하여 클러스터에 액세스합니다.
  3. 오른쪽 상단에 있는 로그인 이름 옆에 있는 드롭다운 화살표를 클릭하고 로그인 명령 복사를 선택합니다.

    새 탭이 열립니다.

  4. 인증 방법을 선택합니다.
  5. 토큰 표시를 클릭합니다.
  6. 이 토큰을 사용하여 로그인 아래에 명령을 복사합니다.
  7. 터미널에서 복사된 명령을 붙여넣고 실행합니다. 로그인에 성공하면 다음 확인 메시지가 표시됩니다.

    $ oc login --token=<your_token> --server=https://api.osd4-demo.abc1.p1.openshiftapps.com:6443
    Logged into "https://api.myrosacluster.abcd.p1.openshiftapps.com:6443" as "rosa-user" using the token provided.
    
    You don't have any projects. You can try to create a new project, by running
    
    oc new-project <project name>
    Copy to Clipboard Toggle word wrap

2.2.2. 새 프로젝트 생성

선호하는 인터페이스를 사용하여 새 프로젝트를 생성합니다.

2.2.2.1. CLI를 사용하여 새 프로젝트 생성

프로세스

  • 다음 명령을 실행하여 클러스터에서 ostoy 라는 새 프로젝트를 생성합니다.

    $ oc new-project ostoy
    Copy to Clipboard Toggle word wrap

    출력 예

    Now using project "ostoy" on server "https://api.myrosacluster.abcd.p1.openshiftapps.com:6443".
    Copy to Clipboard Toggle word wrap

    • 선택 사항: 다음 명령을 실행하여 고유한 프로젝트 이름을 생성합니다.

      $ oc new-project ostoy-$(uuidgen | cut -d - -f 2 | tr '[:upper:]' '[:lower:]')
      Copy to Clipboard Toggle word wrap
2.2.2.2. 웹 콘솔을 사용하여 새 프로젝트 생성

프로세스

  1. 웹 콘솔에서 홈 → 프로젝트를 클릭합니다.
  2. 프로젝트 페이지에서 프로젝트 생성 을 클릭합니다.

  3. 프로젝트 생성 상자의 이름 필드에 프로젝트 이름을 입력합니다.
  4. 생성을 클릭합니다.

2.2.3. 백엔드 마이크로 서비스 배포

마이크로 서비스는 내부 웹 요청을 제공하고 현재 호스트 이름과 무작위로 생성된 색상 문자열이 포함된 JSON 오브젝트를 반환합니다.

프로세스

  • 다음 명령을 실행하여 마이크로 서비스를 배포합니다.

    $ oc apply -f https://raw.githubusercontent.com/openshift-cs/rosaworkshop/master/rosa-workshop/ostoy/yaml/ostoy-microservice-deployment.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    $ oc apply -f https://raw.githubusercontent.com/openshift-cs/rosaworkshop/master/rosa-workshop/ostoy/yaml/ostoy-microservice-deployment.yaml
    deployment.apps/ostoy-microservice created
    service/ostoy-microservice-svc created
    Copy to Clipboard Toggle word wrap

2.2.4. 프런트 엔드 마이크로 서비스 배포

프런트 엔드 배포에서는 애플리케이션 및 추가 Kubernetes 오브젝트에 Node.js 프런트 엔드를 사용합니다.

프론트 엔드 배포는 다음 기능을 정의합니다.

  • 영구 볼륨 클레임
  • Deployment 오브젝트
  • Service
  • 경로
  • ConfigMaps
  • 보안

프로세스

  • 애플리케이션 프런트 엔드를 배포하고 다음 명령을 실행하여 오브젝트를 생성합니다.

    $ oc apply -f https://raw.githubusercontent.com/openshift-cs/rosaworkshop/master/rosa-workshop/ostoy/yaml/ostoy-frontend-deployment.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    persistentvolumeclaim/ostoy-pvc created
    deployment.apps/ostoy-frontend created
    service/ostoy-frontend-svc created
    route.route.openshift.io/ostoy-route created
    configmap/ostoy-configmap-env created
    secret/ostoy-secret-env created
    configmap/ostoy-configmap-files created
    secret/ostoy-secret created
    Copy to Clipboard Toggle word wrap

    모든 오브젝트가 성공적으로 생성되어야 합니다.

2.2.5. 애플리케이션 경로 가져오기

애플리케이션에 액세스할 경로를 가져옵니다.

프로세스

  • 다음 명령을 실행하여 애플리케이션의 경로를 가져옵니다.

    $ oc get route
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME          HOST/PORT                                                 PATH   SERVICES             PORT    TERMINATION   WILDCARD
    ostoy-route   ostoy-route-ostoy.apps.<your-rosa-cluster>.abcd.p1.openshiftapps.com          ostoy-frontend-svc   <all>                 None
    Copy to Clipboard Toggle word wrap

2.2.6. 애플리케이션 보기

프로세스

  1. 이전 단계에서 ostoy-route-ostoy.apps.<your-rosa-cluster>.abcd.p1.openshiftapps.com URL 출력을 복사합니다.
  2. 복사한 URL을 웹 브라우저에 붙여넣고 Enter 키를 누릅니다. 애플리케이션 홈페이지가 표시됩니다. 페이지가 로드되지 않으면 https 가 아닌 http 를 사용해야 합니다.

2.3. 상태 점검

포드를 의도적으로 충돌하고 Kubernetes 활성 프로브에 응답하지 않도록 하여 Kubernetes가 Pod 오류에 응답하는 방법을 참조하십시오.

2.3.1. 데스크탑 준비

프로세스

  • OpenShift 웹 콘솔에서 워크로드 > 배포 > ostoy-frontend 를 선택하여 OSToy 배포를 확인합니다.

2.3.2. Pod 충돌

프로세스

  1. OSToy 애플리케이션 웹 콘솔의 왼쪽 메뉴에서 Home 을 클릭하고 Crash Pod 상자에 메시지를 입력합니다(예: 이 값은 goodbye! ).
  2. Crash Pod 를 클릭합니다.

    Pod가 충돌하고 Kubernetes는 Pod를 다시 시작합니다.

2.3.3. revived Pod 보기

프로세스

  • OpenShift 웹 콘솔에서 신속하게 배포 화면으로 전환합니다. pod가 노란색으로 설정되어 있음을 알 수 있습니다. 이는 다운되었음을 의미합니다. 신속하게 재부팅하고 파란색으로 전환해야 합니다. 재생 프로세스가 빠르게 수행됩니다.

검증

  1. 웹 콘솔에서 포드 > ostoy-frontend-xxxxxxx-xxxx 를 클릭하여 Pod 화면으로 변경합니다.

  2. Events 를 클릭하고 컨테이너가 충돌하여 다시 시작되었는지 확인합니다.

2.3.4. 애플리케이션 오작동으로 만들기

프로세스

~~. Pod 이벤트 페이지를 열린 상태로 유지합니다.~~

  1. OSToy 애플리케이션에서 토글 상태 타일에서 상태 토글 을 클릭합니다. 현재 상태 전환을 볼 수 있습니다. 이 모든 것이 좋지 않습니다.

검증

애플리케이션 오작동을 수행한 후 애플리케이션이 200개의 HTTP 코드로 응답하지 않습니다. Kubernetes는 연속 장애가 3번 실패한 후 Pod를 중지하고 다시 시작합니다.

  • 웹 콘솔에서 Pod 이벤트 페이지로 다시 전환하여 활성 프로브가 실패하고 Pod가 재시작되었는지 확인합니다.

다음 이미지는 Pod 이벤트 페이지에 표시되는 내용의 예를 보여줍니다.

A. Pod에는 3개의 연속 오류가 있습니다.

B. Kubernetes는 Pod를 중지합니다.

C. Kubernetes는 Pod를 다시 시작합니다.

2.4. 클러스터 스토리지를 위한 영구 볼륨

{Rosa-classic-first} 및 Red Hat OpenShift Service on AWS(ROSA)는 AWS( Amazon Web Services) Elastic Block Store(EBS) 또는 AWS Elastic File System(EFS) 을 사용하여 영구 볼륨 저장을 지원합니다.

2.4.1. 영구 볼륨 사용

다음 절차에 따라 파일을 생성하고 클러스터의 영구 볼륨에 저장한 후 Pod가 실패하고 다시 생성되는지 확인합니다.

2.4.1.1. 영구 볼륨 클레임 보기

프로세스

  1. 클러스터의 OpenShift 웹 콘솔로 이동합니다.
  2. 왼쪽 메뉴에서 Storage 를 클릭한 다음 PersistentVolumeClaims 를 클릭하여 모든 영구 볼륨 클레임 목록을 확인합니다.
  3. 지속성 볼륨 클레임을 클릭하여 크기, 액세스 모드, 스토리지 클래스 및 기타 추가 클레임 세부 정보를 확인합니다.

    참고

    액세스 모드는 RWO( ReadWriteOnce )입니다. 즉, 볼륨은 하나의 노드에만 마운트할 수 있으며 Pod 또는 Pod는 볼륨을 읽고 쓸 수 있습니다.

2.4.1.2. 파일 저장

프로세스

  1. OSToy 앱 콘솔의 왼쪽 메뉴에서 영구 스토리지를 클릭합니다.
  2. 파일 이름 상자에 .txt 확장자가 있는 파일 이름을 입력합니다(예: test-pv.txt ).
  3. 파일 콘텐츠 상자에 텍스트 문장을 입력합니다. 예를 들어 OpenShift는 슬라이스된 bread! 이므로 가장 큰 것입니다.
  4. 파일 생성을 클릭합니다.

  5. OSToy 앱 콘솔의 기존 파일로 스크롤합니다.
  6. 생성한 파일을 클릭하여 파일 이름과 내용을 확인합니다.

2.4.1.3. Pod 충돌

프로세스

  1. OSToy 앱 콘솔의 왼쪽 메뉴에서 홈을 클릭합니다.
  2. Crash Pod를 클릭합니다.
2.4.1.4. 영구 스토리지 확인

프로세스

  1. 포드가 다시 생성될 때까지 기다립니다.
  2. OSToy 앱 콘솔의 왼쪽 메뉴에서 영구 스토리지를 클릭합니다.
  3. 만든 파일을 찾아서 열어 내용을 보고 확인합니다.

검증

배포 YAML 파일은 /var/demo_files 디렉토리를 영구 볼륨 클레임에 마운트했음을 보여줍니다.

  1. 다음 명령을 실행하여 프런트 엔드 Pod의 이름을 검색합니다.

    $ oc get pods
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 컨테이너에서 SSH(Secure Shell) 세션을 시작합니다.

    $ oc rsh <pod_name>
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 디렉터리로 이동합니다.

    $ cd /var/demo_files
    Copy to Clipboard Toggle word wrap
  4. 선택 사항: 다음 명령을 실행하여 생성한 모든 파일을 확인합니다.

    $ ls
    Copy to Clipboard Toggle word wrap
  5. 다음 명령을 실행하여 내용을 보려면 파일을 엽니다.

    $ cat test-pv.txt
    Copy to Clipboard Toggle word wrap
  6. 출력이 OSToy 앱 콘솔에 입력한 텍스트인지 확인합니다.

    터미널 예

    $ oc get pods
    NAME                                  READY     STATUS    RESTARTS   AGE
    ostoy-frontend-5fc8d486dc-wsw24       1/1       Running   0          18m
    ostoy-microservice-6cf764974f-hx4qm   1/1       Running   0          18m
    
    $ oc rsh ostoy-frontend-5fc8d486dc-wsw24
    
    $ cd /var/demo_files/
    
    $ ls
    lost+found   test-pv.txt
    
    $ cat test-pv.txt
    OpenShift is the greatest thing since sliced bread!
    Copy to Clipboard Toggle word wrap

2.4.1.5. 세션 종료

프로세스

  • 터미널에 exit 를 입력하여 세션을 종료하고 CLI로 돌아갑니다.

2.5. ConfigMaps, 보안 및 환경 변수

이 튜토리얼에서는 구성 ,시크릿환경 변수 를 사용하여 OSToy 애플리케이션을 구성하는 방법을 보여줍니다.

2.5.1. ConfigMap을 사용한 구성

구성 맵을 사용하면 컨테이너 이미지 콘텐츠에서 구성 아티팩트를 분리하여 컨테이너화된 애플리케이션을 이식할 수 있습니다.

프로세스

  • OSToy 앱의 왼쪽 메뉴에서 Config Maps 을 클릭하여 OSToy 애플리케이션에서 사용할 수 있는 구성 맵의 내용을 표시합니다. 코드 스니펫은 구성 맵 구성의 예를 보여줍니다.

    출력 예

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: ostoy-configmap-files
    data:
      config.json:  '{ "default": "123" }'
    Copy to Clipboard Toggle word wrap

2.5.2. 보안을 사용한 구성

Kubernetes Secret 오브젝트를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리할 수 있습니다. 이 정보를 시크릿에 배치하는 것은 포드 정의 또는 컨테이너 이미지에 일반 텍스트에 배치하는 것보다 더 안전하고 유연합니다.

프로세스

  • OSToy 앱의 왼쪽 메뉴에서 시크릿을 클릭하여 OSToy 애플리케이션에서 사용할 수 있는 시크릿 내용을 표시합니다. 코드 스니펫은 보안 구성의 예를 보여줍니다.

    출력 예

    USERNAME=my_user
    PASSWORD=VVNFUk5BTUU9bXlfdXNlcgpQQVNTV09SRD1AT3RCbCVYQXAhIzYzMlk1RndDQE1UUWsKU01UUD1sb2NhbGhvc3QKU01UUF9QT1JUPTI1
    SMTP=localhost
    SMTP_PORT=25
    Copy to Clipboard Toggle word wrap

2.5.3. 환경 변수를 사용한 구성

환경 변수를 사용하면 코드를 변경할 필요 없이 애플리케이션 동작을 쉽게 변경할 수 있습니다. 동일한 애플리케이션의 다양한 배포가 환경 변수에 따라 다르게 작동할 수 있습니다. Red Hat OpenShift Service on AWS를 사용하면 Pod 또는 배포의 환경 변수를 쉽게 설정, 보기 및 업데이트할 수 있습니다.

프로세스

  • OSToy 앱의 왼쪽 메뉴에서 ENV 변수 를 클릭하여 OSToy 애플리케이션에서 사용할 수 있는 환경 변수를 표시합니다. 코드 스니펫은 환경 변수 구성의 예를 보여줍니다.

    출력 예

    {
      "npm_config_local_prefix": "/opt/app-root/src",
      "STI_SCRIPTS_PATH": "/usr/libexec/s2i",
      "npm_package_version": "1.7.0",
      "APP_ROOT": "/opt/app-root",
      "NPM_CONFIG_PREFIX": "/opt/app-root/src/.npm-global",
      "OSTOY_MICROSERVICE_PORT_8080_TCP_PORT": "8080",
      "NODE": "/usr/bin/node",
      "LD_PRELOAD": "libnss_wrapper.so",
      "KUBERNETES_SERVICE_HOST": "172.30.0.1",
      "OSTOY_MICROSERVICE_PORT": "tcp://172.30.60.255:8080",
      "OSTOY_PORT": "tcp://172.30.152.25:8080",
      "npm_package_name": "ostoy",
      "OSTOY_SERVICE_PORT_8080_TCP": "8080",
      "_": "/usr/bin/node"
      "ENV_TOY_CONFIGMAP": "ostoy-configmap -env"
    }
    Copy to Clipboard Toggle word wrap

2.6. 네트워킹

OSToy 애플리케이션은 마이크로 서비스를 사용하여 클러스터 내 네트워킹을 사용하여 기능을 분리합니다.

이 워크샵에는 두 개 이상의 개별 Pod가 있으며 각각 자체 서비스가 있습니다. 하나의 pod는 서비스와 공개적으로 액세스 가능한 경로를 사용하여 프런트 엔드 웹 애플리케이션으로 작동합니다. 다른 pod는 서비스 오브젝트를 사용하여 backend 마이크로 서비스로 작동하므로 프런트 엔드 포드에서 마이크로 서비스와 통신할 수 있습니다.

Pod가 두 개 이상인 경우 Pod에서 통신이 수행됩니다. 마이크로 서비스는 클러스터 및 기타 네임스페이스 또는 프로젝트 외부에서 액세스할 수 없습니다. 마이크로 서비스의 목적은 내부 웹 요청을 제공하고 현재 호스트 이름(Pod의 이름)과 무작위로 생성된 색상 문자열이 포함된 JSON 오브젝트를 반환하는 것입니다. 이 색상 문자열에는 OSToy 애플리케이션 웹 콘솔에 해당 색상이 있는 상자가 표시됩니다.

네트워킹 제한에 대한 자세한 내용은 네트워크 정책 정보를 참조하십시오.

2.6.1. 클러스터 내 네트워킹

OSToy 애플리케이션에서 네트워킹 구성을 볼 수 있습니다.

프로세스

  1. OSToy 애플리케이션 웹 콘솔의 왼쪽 메뉴에서 네트워킹 을 클릭합니다.
  2. 네트워킹 구성을 검토합니다. 타일 "Hostname Lookup"은 Pod에 대해 생성된 서비스 이름이 내부 ClusterIP 주소로 변환되는 방법을 보여줍니다.

  3. < service_name>.<namespace>.svc.cluster.local 형식의 "Hostname Lookup" 타일에 생성된 마이크로 서비스의 이름을 입력합니다. 다음 명령을 실행하여 ostoy-microservice.yaml 의 서비스 정의에서 마이크로 서비스 이름을 찾을 수 있습니다.

    $ oc get service <name_of_service> -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
    kind: Service
    metadata:
      name: ostoy-microservice-svc
      labels:
        app: ostoy-microservice
    spec:
      type: ClusterIP
      ports:
        - port: 8080
          targetPort: 8080
          protocol: TCP
      selector:
        app: ostoy-microservice
    Copy to Clipboard Toggle word wrap

    이 예에서 전체 호스트 이름은 ostoy-microservice-svc.ostoy.svc.cluster.local 입니다.

  4. IP 주소가 반환됩니다. 이 예에서는 172.30.165.246 입니다. 클러스터 내 IP 주소이며 클러스터 내에서만 액세스할 수 있습니다.

2.7. 애플리케이션 스케일링

HPA(horizontal Pod Autoscaler)를 사용하여 Pod를 수동으로 또는 자동으로 스케일링합니다. 클러스터 노드를 확장할 수도 있습니다.

사전 요구 사항

  • 활성 ROSA 클러스터
  • 배포된 OSToy 애플리케이션

2.7.1. 수동 Pod 스케일링

다음 방법 중 하나를 사용하여 애플리케이션 Pod를 수동으로 스케일링할 수 있습니다.

  • ReplicaSet 또는 배포 정의 변경
  • 명령줄 사용
  • 웹 콘솔 사용

이 워크샵은 마이크로 서비스에 하나의 Pod만 사용하여 시작됩니다. 배포 정의에서 1 개의 복제본을 정의하면 Kubernetes Replication Controller에서 하나의 Pod를 활성 상태로 유지합니다. 그런 다음 부하를 기반으로 Horizontal Pod Autoscaler(HPA)를 사용하여 Pod 자동 스케일링을 정의하고 필요한 경우 더 많은 Pod를 확장하는 방법을 알아봅니다.

프로세스

  1. OSToy 앱의 탐색 메뉴에서 네트워킹 탭을 클릭합니다.
  2. "Intra-cluster communication" 섹션에서 무작위로 색상을 변경하는 상자를 찾습니다. 박스 내에는 마이크로 서비스의 포드 이름이 표시됩니다. 마이크로 서비스 pod가 하나뿐이므로 이 예제에는 하나의 박스만 있습니다.

  3. 다음 명령을 실행하여 마이크로 서비스에 대해 실행 중인 포드가 하나뿐인지 확인합니다.

    $ oc get pods
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                  READY     STATUS    RESTARTS   AGE
    ostoy-frontend-679cb85695-5cn7x       1/1       Running   0          1h
    ostoy-microservice-86b4c6f559-p594d   1/1       Running   0          1h
    Copy to Clipboard Toggle word wrap

  4. ostoy-microservice-deployment.yaml 을 다운로드하여 로컬 머신에 저장합니다.
  5. 다음 예제를 사용하여 배포 정의를 1개 대신 3개의 Pod로 변경합니다.

    spec:
        selector:
          matchLabels:
            app: ostoy-microservice
        replicas: 3
    Copy to Clipboard Toggle word wrap
  6. 다음 명령을 실행하여 복제본 변경 사항을 적용합니다.

    $ oc apply -f ostoy-microservice-deployment.yaml
    Copy to Clipboard Toggle word wrap
    참고

    워크로드 > Deployments > ostoy-microservice > YAML 탭으로 이동하여 OpenShift 웹 콘솔에서 ostoy-microservice- deployment.yaml 파일을 편집할 수도 있습니다.

  7. 다음 명령을 실행하여 Pod 3개가 있는지 확인합니다.

    $ oc get pods
    Copy to Clipboard Toggle word wrap

    출력에서는 이제 마이크로 서비스에 대한 포드가 하나만 아니라 3개의 포드가 있음을 보여줍니다.

    출력 예

    NAME                                  READY   STATUS    RESTARTS   AGE
    ostoy-frontend-5fbcc7d9-rzlgz         1/1     Running   0          26m
    ostoy-microservice-6666dcf455-2lcv4   1/1     Running   0          81s
    ostoy-microservice-6666dcf455-5z56w   1/1     Running   0          81s
    ostoy-microservice-6666dcf455-tqzmn   1/1     Running   0          26m
    Copy to Clipboard Toggle word wrap

  8. CLI(명령줄 인터페이스)를 사용하거나 웹 UI(사용자 인터페이스)를 사용하여 애플리케이션을 확장합니다.

    • CLI에서 다음 명령을 실행하여 Pod 수를 3 에서 2 로 줄입니다.

      $ oc scale deployment ostoy-microservice --replicas=2
      Copy to Clipboard Toggle word wrap
    • OpenShift 웹 콘솔 UI의 탐색 메뉴에서 워크로드 > 배포 > ostoy-microservice 를 클릭합니다.
    • 중간에서 "3 Pod" 라벨이 있는 파란색 원을 찾습니다.
    • 원 옆에 있는 화살표를 선택하면 Pod 수가 스케일링됩니다. 2 의 아래쪽 화살표를 선택합니다.

검증

CLI, 웹 UI 또는 OSToy 애플리케이션을 사용하여 Pod 수를 확인합니다.

  • CLI에서 다음 명령을 실행하여 마이크로 서비스에 두 개의 포드를 사용하고 있는지 확인합니다.

    $ oc get pods
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                  READY   STATUS    RESTARTS   AGE
    ostoy-frontend-5fbcc7d9-rzlgz         1/1     Running   0          75m
    ostoy-microservice-6666dcf455-2lcv4   1/1     Running   0          50m
    ostoy-microservice-6666dcf455-tqzmn   1/1     Running   0          75m
    Copy to Clipboard Toggle word wrap

  • 웹 UI에서 워크로드 > 배포 > ostoy-microservice 를 선택합니다.

  • OSToy 애플리케이션의 탐색 메뉴에서 네트워킹을 선택하여 개의 포드가 있는지 확인할 수도 있습니다. 두 Pod에는 두 개의 색상이 지정된 박스가 있어야 합니다.

2.7.2. Pod 자동 스케일링

AWS의 Red Hat OpenShift Service는 Horizontal Pod Autoscaler (HPA)를 제공합니다. HPA는 필요한 경우 메트릭을 사용하여 Pod 수를 늘리거나 줄입니다.

프로세스

  1. 웹 UI의 탐색 메뉴에서 Pod 자동 스케일링을 선택합니다.

  2. 다음 명령을 실행하여 HPA를 생성합니다.

    $ oc autoscale deployment/ostoy-microservice --cpu-percent=80 --min=1 --max=10
    Copy to Clipboard Toggle word wrap

    이 명령은 ostoy-microservice 배포에서 제어하는 Pod의 복제본 1~10개 사이를 유지 관리하는 HPA를 생성합니다. 배포 중에 HPA는 모든 Pod에서 평균 CPU 사용을 80% 및 40밀리코어로 유지하기 위해 복제본 수를 늘리고 줄입니다.

  3. Pod 자동 확장 > Horizontal Pod 자동 확장 페이지에서 로드 증가를 선택합니다.

    중요

    부하를 늘리면 CPU 집약적 계산이 생성되므로 페이지가 응답하지 않을 수 있습니다. 이는 예상된 응답입니다. 로드를 한 번만 늘리십시오. 프로세스에 대한 자세한 내용은 마이크로 서비스의 GitHub 리포지토리 를 참조하십시오.

    몇 분 후에 새 Pod가 색상이 지정된 박스로 표시되는 페이지에 표시됩니다.

    참고

    이 페이지는 지연이 발생할 수 있습니다.

검증

다음 방법 중 하나를 사용하여 Pod 수를 확인합니다.

  • OSToy 애플리케이션의 웹 UI에서 원격 pod 상자를 참조하십시오.

    Pod가 하나뿐이므로 워크로드를 늘리면 Pod 증가가 트리거됩니다.

  • CLI에서 다음 명령을 실행합니다.

    oc get pods --field-selector=status.phase=Running | grep microservice
    Copy to Clipboard Toggle word wrap

    출력 예

    ostoy-microservice-79894f6945-cdmbd   1/1     Running   0          3m14s
    ostoy-microservice-79894f6945-mgwk7   1/1     Running   0          4h24m
    ostoy-microservice-79894f6945-q925d   1/1     Running   0          3m14s
    Copy to Clipboard Toggle word wrap

  • OpenShift Cluster Manager에서 자동 스케일링을 확인할 수도 있습니다.

    1. OpenShift 웹 콘솔 탐색 메뉴에서 모니터링 > 대시보드를 클릭합니다.
    2. 대시보드에서 Kubernetes / Compute Resources / Namespace (Pods) 및 네임스페이스 ostoy 를 선택합니다.

    3. CPU 및 메모리 전반에 걸쳐 리소스 사용량이 표시되는 그래프가 표시됩니다. 상단 그래프는 Pod당 최근 CPU 사용량이 표시되고 더 낮은 그래프는 메모리 사용량을 나타냅니다. 다음은 그래프의 호출을 나열합니다.

      1. 부하 증가(A).
      2. 두 개의 새 Pod(B 및 C)가 생성되었습니다.
      3. 각 그래프의 간격은 CPU 소비를 나타내며 더 많은 로드를 처리하는 Pod를 나타냅니다.
      4. 로드가 감소하고 Pod가 삭제되었습니다.

2.7.3. 노드 자동 스케일링

AWS의 Red Hat OpenShift Service를 사용하면 노드 자동 스케일링을 사용할 수 있습니다. 이 시나리오에서는 클러스터가 처리할 수 없는 대규모 워크로드가 있는 작업으로 새 프로젝트를 생성합니다. 자동 스케일링이 활성화되면 로드가 현재 용량보다 크면 클러스터에서 자동으로 로드를 처리할 새 노드를 생성합니다.

사전 요구 사항

  • 머신 풀에서 자동 스케일링이 활성화됩니다.

프로세스

  1. 다음 명령을 실행하여 autoscale-ex 라는 새 프로젝트를 생성합니다.

    $ oc new-project autoscale-ex
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 작업을 생성합니다.

    $ oc create -f https://raw.githubusercontent.com/openshift-cs/rosaworkshop/master/rosa-workshop/ostoy/yaml/job-work-queue.yaml
    Copy to Clipboard Toggle word wrap
  3. 몇 가지 minuts 후 다음 명령을 실행하여 Pod를 확인합니다.

    $ oc get pods
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                     READY   STATUS    RESTARTS   AGE
    work-queue-5x2nq-24xxn   0/1     Pending   0          10s
    work-queue-5x2nq-57zpt   0/1     Pending   0          10s
    work-queue-5x2nq-58bvs   0/1     Pending   0          10s
    work-queue-5x2nq-6c5tl   1/1     Running   0          10s
    work-queue-5x2nq-7b84p   0/1     Pending   0          10s
    work-queue-5x2nq-7hktm   0/1     Pending   0          10s
    work-queue-5x2nq-7md52   0/1     Pending   0          10s
    work-queue-5x2nq-7qgmp   0/1     Pending   0          10s
    work-queue-5x2nq-8279r   0/1     Pending   0          10s
    work-queue-5x2nq-8rkj2   0/1     Pending   0          10s
    work-queue-5x2nq-96cdl   0/1     Pending   0          10s
    work-queue-5x2nq-96tfr   0/1     Pending   0          10s
    Copy to Clipboard Toggle word wrap

  4. Pending 상태에 Pod가 많이 있으므로 이 상태는 자동 스케일러를 트리거하여 머신 풀에 더 많은 노드를 생성합니다. 이러한 작업자 노드를 생성하는 시간을 허용합니다.
  5. 몇 분 후에 다음 명령을 사용하여 현재 보유하고 있는 작업자 노드 수를 확인합니다.

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                         STATUS   ROLES          AGE     VERSION
    ip-10-0-138-106.us-west-2.compute.internal   Ready    infra,worker   22h     v1.23.5+3afdacb
    ip-10-0-153-68.us-west-2.compute.internal    Ready    worker         2m12s   v1.23.5+3afdacb
    ip-10-0-165-183.us-west-2.compute.internal   Ready    worker         2m8s    v1.23.5+3afdacb
    ip-10-0-176-123.us-west-2.compute.internal   Ready    infra,worker   22h     v1.23.5+3afdacb
    ip-10-0-195-210.us-west-2.compute.internal   Ready    master         23h     v1.23.5+3afdacb
    ip-10-0-196-84.us-west-2.compute.internal    Ready    master         23h     v1.23.5+3afdacb
    ip-10-0-203-104.us-west-2.compute.internal   Ready    worker         2m6s    v1.23.5+3afdacb
    ip-10-0-217-202.us-west-2.compute.internal   Ready    master         23h     v1.23.5+3afdacb
    ip-10-0-225-141.us-west-2.compute.internal   Ready    worker         23h     v1.23.5+3afdacb
    ip-10-0-231-245.us-west-2.compute.internal   Ready    worker         2m11s   v1.23.5+3afdacb
    ip-10-0-245-27.us-west-2.compute.internal    Ready    worker         2m8s    v1.23.5+3afdacb
    ip-10-0-245-7.us-west-2.compute.internal     Ready    worker         23h     v1.23.5+3afdacb
    Copy to Clipboard Toggle word wrap

    워크로드를 처리하기 위해 작업자 노드가 자동으로 생성되었는지 확인할 수 있습니다.

  6. 다음 명령을 입력하여 OSToy 애플리케이션으로 돌아갑니다.

    $ oc project ostoy
    Copy to Clipboard Toggle word wrap

2.8. S2I 배포

통합된 S2I(Source-to-Image) 빌더는 OpenShift에 애플리케이션을 배포하는 방법 중 하나입니다. S2I는 재현 가능한 Docker 형식의 컨테이너 이미지를 빌드하는 툴입니다. 자세한 내용은 OpenShift 개념을 참조하십시오.

사전 요구 사항

  • ROSA 클러스터

2.8.1. 로그인 명령 검색

프로세스

  1. 다음 명령을 실행하여 CLI(명령줄 인터페이스)에 로그인했는지 확인합니다.

    rosa whoami
    Copy to Clipboard Toggle word wrap

    명령줄 인터페이스에 로그인한 경우 "새 프로젝트 생성"으로 건너뜁니다. 명령줄 인터페이스에 로그인하지 않은 경우 이 절차를 계속합니다.

  2. OpenShift Cluster Manager 에서 CLI(명령줄 인터페이스)에 로그인하지 않은 경우 오른쪽 상단에 있는 이름 옆에 있는 드롭다운 화살표를 클릭하고 로그인 명령 복사를 선택합니다.

  3. 새 탭이 열립니다. 사용자 이름과 암호를 입력하고 인증 방법을 선택합니다.
  4. 토큰 표시를클릭합니다.
  5. "이 토큰을 사용하여 로그인"에서 명령을 복사합니다.
  6. 터미널에서 복사한 명령을 실행하여 CLI에 로그인합니다.

    입력 예

    $ oc login --token=RYhFlXXXXXXXXXXXX --server=https://api.osd4-demo.abc1.p1.openshiftapps.com:6443
    Copy to Clipboard Toggle word wrap

    출력 예

    Logged into "https://api.myrosacluster.abcd.p1.openshiftapps.com:6443" as "rosa-user" using the token provided.
    
    You don't have any projects. You can try to create a new project, by running
    
    oc new-project <project name>
    Copy to Clipboard Toggle word wrap

2.8.2. 새 프로젝트 생성

  • 다음 명령을 실행하여 CLI에서 새 프로젝트를 생성합니다.

    $ oc new-project ostoy-s2i
    Copy to Clipboard Toggle word wrap

2.8.3. OSToy 리포지토리 분기

소스 코드 변경에 따라 자동화된 빌드를 트리거하려면 GitHub Webhook를 설정해야 합니다. GitHub 리포지토리로 코드를 내보낼 때 Webhook에서 S2I 빌드를 트리거합니다. Webhook를 설정하려면 먼저 리포지토리를 분기해야 합니다.

중요

이 가이드에서 < UserName >을 다음 URL의 고유한 GitHub 사용자 이름으로 바꿉니다.

2.8.4. S2i를 사용하여 클러스터에 OSToy 배포

프로세스

  1. OpenShift에 시크릿을 추가합니다.

    이 예제에서는 .env 파일을 에뮬레이션합니다. 파일은 OpenShift 환경으로 직접 이동할 수 있으며 시크릿에서 이름을 변경할 수도 있습니다.

    • 다음 명령을 실행하여 < UserName>을 GitHub 사용자 이름으로 교체합니다.

      $ oc create -f https://raw.githubusercontent.com/<UserName>/ostoy/master/deployment/yaml/secret.yaml
      Copy to Clipboard Toggle word wrap
  2. OpenShift에 ConfigMap을 추가합니다.

    이 예제에서는 일반적으로 OpenShift 애플리케이션에서 기본 구성을 재정의하는 데 사용되는 HAProxy 구성 파일을 에뮬레이션합니다. ConfigMap에서 파일의 이름을 변경할 수 있습니다.

    • 다음 명령을 실행하여 < UserName>을 GitHub 사용자 이름으로 교체합니다.

      $ oc create -f https://raw.githubusercontent.com/<UserName>/ostoy/master/deployment/yaml/configmap.yaml
      Copy to Clipboard Toggle word wrap
  3. 마이크로 서비스를 배포합니다.

    UI 애플리케이션에서 서비스 환경 변수를 사용할 수 있도록 마이크로 서비스를 배포해야 합니다.

    --context-dir 은 Git 리포지토리의 마이크로 서비스 디렉터리에 정의된 애플리케이션을 빌드합니다. app 레이블을 사용하면 UI(사용자 인터페이스) 애플리케이션 및 마이크로 서비스가 모두 OpenShift UI로 그룹화됩니다.

    • 다음 명령을 실행하여 마이크로 서비스를 생성하고 < UserName& gt;을 GitHub 사용자 이름으로 교체합니다.

      $ oc new-app https://github.com/<UserName>/ostoy \
          --context-dir=microservice \
          --name=ostoy-microservice \
          --labels=app=ostoy
      Copy to Clipboard Toggle word wrap

      출력 예

      --> Creating resources with label app=ostoy ...
          imagestream.image.openshift.io "ostoy-microservice" created
          buildconfig.build.openshift.io "ostoy-microservice" created
          deployment.apps "ostoy-microservice" created
          service "ostoy-microservice" created
      --> Success
          Build scheduled, use 'oc logs -f buildconfig/ostoy-microservice' to track its progress.
          Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
           'oc expose service/ostoy-microservice'
          Run 'oc status' to view your app.
      Copy to Clipboard Toggle word wrap

  4. 마이크로 서비스의 상태를 확인합니다.

    • 다음 명령을 실행하여 마이크로 서비스가 생성되었고 올바르게 실행되고 있는지 확인합니다.

      $ oc status
      Copy to Clipboard Toggle word wrap

      출력 예

      In project ostoy-s2i on server https://api.myrosacluster.g14t.p1.openshiftapps.com:6443
      
      svc/ostoy-microservice - 172.30.47.74:8080
        dc/ostoy-microservice deploys istag/ostoy-microservice:latest <-
          bc/ostoy-microservice source builds https://github.com/UserName/ostoy on openshift/nodejs:14-ubi8
          deployment #1 deployed 34 seconds ago - 1 pod
      Copy to Clipboard Toggle word wrap

      마이크로 서비스가 성공적으로 배포될 때까지 기다립니다. 웹 UI를 통해 이를 확인할 수도 있습니다.

  5. 프런트 엔드 UI를 배포합니다.

    애플리케이션은 여러 환경 변수를 사용하여 외부 설정을 정의합니다.

    • 보안 및 ConfigMap을 연결하고 다음 명령을 실행하여 PersistentVolume을 생성합니다.

      $ oc new-app https://github.com/<UserName>/ostoy \
          --env=MICROSERVICE_NAME=OSTOY_MICROSERVICE
      Copy to Clipboard Toggle word wrap

      출력 예

      --> Creating resources ...
          imagestream.image.openshift.io "ostoy" created
          buildconfig.build.openshift.io "ostoy" created
          deployment.apps "ostoy" created
          service "ostoy" created
      --> Success
          Build scheduled, use 'oc logs -f buildconfig/ostoy' to track its progress.
          Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
           'oc expose service/ostoy'
          Run 'oc status' to view your app.
      Copy to Clipboard Toggle word wrap

  6. 다음 명령을 실행하여 배포를 업데이트합니다.

    $ oc patch deployment ostoy --type=json -p \
        '[{"op": "replace", "path": "/spec/strategy/type", "value": "Recreate"}, {"op": "remove", "path": "/spec/strategy/rollingUpdate"}]'
    Copy to Clipboard Toggle word wrap
  7. 활성 프로브를 설정합니다.

    활성 프로브를 생성하여 애플리케이션에서 문제가 발생하면 포드가 다시 시작되는지 확인합니다.

    • 다음 명령을 실행합니다.

      $ oc set probe deployment ostoy --liveness --get-url=http://:8080/health
      Copy to Clipboard Toggle word wrap
  8. 시크릿, ConfigMap 및 영구 볼륨을 배포에 연결합니다.

    1. 다음 명령을 실행하여 보안을 연결합니다.

      $ oc set volume deployment ostoy --add \
          --secret-name=ostoy-secret \
          --mount-path=/var/secret
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 ConfigMap을 연결합니다.

      $ oc set volume deployment ostoy --add \
          --configmap-name=ostoy-config \
          -m /var/config
      Copy to Clipboard Toggle word wrap
    3. 다음 명령을 실행하여 영구 볼륨을 생성하고 연결합니다.

      $ oc set volume deployment ostoy --add \
          --type=pvc \
          --claim-size=1G \
          -m /var/demo_files
      Copy to Clipboard Toggle word wrap
  9. UI 애플리케이션을 OpenShift 경로로 노출합니다.

    • 다음 명령을 실행하여 포함된 TLS 와일드카드 인증서를 사용하는 HTTPS 애플리케이션으로 애플리케이션을 배포합니다.

      $ oc create route edge --service=ostoy --insecure-policy=Redirect
      Copy to Clipboard Toggle word wrap
  10. 다음 방법을 사용하여 애플리케이션을 찾습니다.

    • 다음 명령을 실행하여 OSToy 애플리케이션으로 웹 브라우저를 엽니다.

      $ python -m webbrowser "$(oc get route ostoy -o template --template='https://{{.spec.host}}')"
      Copy to Clipboard Toggle word wrap
    • 다음 명령을 실행하여 애플리케이션의 경로를 가져오고 브라우저에 경로를 복사하여 붙여넣습니다.

      $ oc get route
      Copy to Clipboard Toggle word wrap

2.9. 자동 배포에 S2I(Source-to-Image) Webhook 사용

Webhook를 사용하여 소스 코드를 변경할 때마다 빌드를 자동으로 트리거하고 배포합니다. 이 프로세스에 대한 자세한 내용은 빌드 트리거를 참조하십시오.

프로세스

  1. 다음 명령을 실행하여 GitHub Webhook 트리거 시크릿을 가져옵니다.

    $ oc get bc/ostoy-microservice -o=jsonpath='{.spec.triggers..github.secret}'
    Copy to Clipboard Toggle word wrap

    출력 예

    `o_3x9M1qoI2Wj_cz1WiK`
    Copy to Clipboard Toggle word wrap

    중요

    이 프로세스의 이후 단계에서 이 시크릿을 사용해야 합니다.

  2. 다음 명령을 실행하여 OSToy의 buildconfig에서 GitHub Webhook 트리거 URL을 가져옵니다.

    $ oc describe bc/ostoy-microservice
    Copy to Clipboard Toggle word wrap

    출력 예

    [...]
    Webhook GitHub:
    	URL:	https://api.demo1234.openshift.com:443/apis/build.openshift.io/v1/namespaces/ostoy-s2i/buildconfigs/ostoy/webhooks/<secret>/github
    [...]
    Copy to Clipboard Toggle word wrap

  3. GitHub Webhook URL에서 < secret> 텍스트를 검색한 시크릿으로 바꿉니다. URL은 다음 예제 출력과 유사합니다.

    출력 예

    https://api.demo1234.openshift.com:443/apis/build.openshift.io/v1/namespaces/ostoy-s2i/buildconfigs/ostoy-microservice/webhooks/o_3x9M1qoI2Wj_czR1WiK/github
    Copy to Clipboard Toggle word wrap

  4. GitHub 리포지토리에 Webhook URL을 설정합니다.

    1. 리포지토리에서 설정 > Webhook > Webhook 추가 를 클릭합니다.

    2. "Payload URL" 필드에 포함된 Secret 을 사용하여 GitHub Webhook URL을 붙여넣습니다.
    3. "Content type"을 application/json 으로 변경합니다.
    4. Webhook 추가 버튼을 클릭합니다.

      GitHub에서 Webhook가 성공적으로 구성되었음을 알리는 메시지가 표시됩니다. 이제 GitHub 리포지토리에 변경 사항을 푸시할 때마다 새 빌드가 자동으로 시작되고 빌드가 성공하면 새 배포가 시작됩니다.

  5. 소스 코드를 변경합니다. 모든 변경 사항은 빌드 및 배포를 자동으로 트리거합니다. 이 예에서는 OSToy 앱의 상태를 나타내는 색상이 임의로 선택됩니다. 구성을 테스트하려면 회색 스케일링을 표시하도록 상자를 변경합니다.

    1. 리포지토리의 소스 코드로 이동합니다 https://github.com/<username>/ostoy/blob/master/microservice/app.js.
    2. 파일을 편집합니다.
    3. 8행을 주석으로 주석 처리(로우를 허용하면 random color = getRandom Cryostat();).
    4. Uncomment line 9 (containing let randomColor = getRandomGrayScaleColor();).

      7   app.get('/', function(request, response) {
      8   //let randomColor = getRandomColor(); // <-- comment this
      9   let randomColor = getRandomGrayScaleColor(); // <-- uncomment this
      10
      11  response.writeHead(200, {'Content-Type': 'application/json'});
      Copy to Clipboard Toggle word wrap
    5. "Graphscale 색상으로 변경됨"과 같은 업데이트 메시지를 입력합니다.
    6. 하단에서 커밋 을 클릭하여 기본 분기에 대한 변경 사항을 커밋합니다.
  6. 클러스터의 웹 UI에서 빌드 > 빌드 를 클릭하여 빌드 상태를 확인합니다. 이 빌드가 완료되면 배포가 시작됩니다. 터미널에서 oc 상태를 실행하여 상태를 확인할 수도 있습니다.

  7. 배포가 완료되면 브라우저의 OSToy 애플리케이션으로 돌아갑니다. 왼쪽의 Networking 메뉴 항목에 액세스합니다. 이제 상자 색상은 회색 영역 색상으로만 제한됩니다.

Legal Notice

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat