Istio Hands-on Study [1기] - 8주차 - VM Support & Istio Traffic Flow - 13장

개요

`This chapter covers` *Incorporating virtual machine workloads into the mesh*

- 레거시 워크로드를 이스티오 서비스 메시에 통합하기 *Incorporating legacy workloads into Istio’s service mesh*
- 가상머신에 istio-agent 설치 및 설정하기 *Installing and configuring the istio-agent in VMs*
- 가상머신에 ID 프로비저닝하기 *Provisioning identity for VMs*
- 클러스터 서비스와 가상머신 서비스를 서로 노출하기 *Exposing cluster services to VMs, and vice versa*
- 로컬 DNS 프록시를 사용해 클러스터 서비스의 FQDN 해석하기 *Using the local DNS proxy to resolve FQDNs of cluster services*

 

들어가며

https://istio.io/v1.17/blog/2021/simple-vms/

• 지금까지는 이스티오 서비스 메시를 컨테이너 및 쿠버네티스 관점에서 다뤘다.
• 그러나 실제 워크로드는 자주 가상머신이나 물리 머신에서 실행된다.
• 컨테이너와 쿠버네티스는 종종 기술 스택을 현대화하려는 노력의 일환으로 사용하며, 이번 장은 이 두 세계를 애플리케이션 네트워크 계층에서 이스티오로 연결하는 방법을 보여준다.
• 왜 단순히 레거시 워크로드를 현대화해서 쿠버네티스 클러스터에서 실행하는 것이 아니라 가상머신을 메시로 통합하는 것인지 궁금할 수 있다.
• 우리도 가능하면 그 접근법을 추천하지만, 몇몇 경우에는 그런 접근법이 불가능하거나 최소한 비용을 고려했을 때 불가능에 가까울 수 있다.
• 엔터프라이즈는 규제 준수 때문에 워크로드를 쿠버네티스 클러스터를 설정하고 운영할 전문 지식이 부족한 온프레미스에서 실행해야 할 수 있다.
• 애플리케이션을 컨테이너화하는 것은 그리 간단하지 않다. 어떤 애플리케이션은 다시 설계해야 할 수 있다. 어떤 애플리케이션에는 업데이트해야 하지만 다른 의존성과 충돌하는 의존성이 있을 수 있다. 즉, 의존성 지옥이다.
• 어떤 것들은 실행 중인 가상머신에 고유한 의존성이 있다. Some have some unique dependencies on the VM they run on.
• 이번 장에서는 사이드카 프록시를 설치하고 설정함으로써 어떤 워크로드든 메시의 일부로 삼을 수 있는 방법을 보여준다.
• 이 접근법은 레거시 워크로드가 있으며, 이 레거시 워크로드를 복원력 있고 안전하고 고가용성적인 방식으로 메시로 통합하길 원하는 엔터프라이즈에게 흥미로운 기능을 제공한다.

 

실습 환경 구성

구성 : VPC 1개, EC2 인스턴스 1대 (Ubuntu 22.04 LTS, t3.xlarge - vCPU 4 , Mem 16) , forum-vm 1대는 t3.small

• CloudFormation 스택 실행 시 파라미터를 기입하면, 해당 정보가 반영되어 배포됩니다.
• CloudFormation 에 EC2의 UserData 부분(Script 실행)으로 실습 환경에 필요한 기본 설정들이 자동으로 진행됩니다.

AWSTemplateFormatVersion: '2010-09-09'

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
      - Label:
          default: "<<<<< Deploy EC2 >>>>>"
        Parameters:
          - KeyName
          - SgIngressSshCidr
          - MyInstanceType
          - LatestAmiId

      - Label:
          default: "<<<<< Region AZ >>>>>"
        Parameters:
          - TargetRegion
          - AvailabilityZone1
          - AvailabilityZone2

      - Label:
          default: "<<<<< VPC Subnet >>>>>"
        Parameters:
          - VpcBlock
          - PublicSubnet1Block
          - PublicSubnet2Block

Parameters:
  KeyName:
    Description: Name of an existing EC2 KeyPair to enable SSH access to the instances.
    Type: AWS::EC2::KeyPair::KeyName
    ConstraintDescription: must be the name of an existing EC2 KeyPair.
  SgIngressSshCidr:
    Description: The IP address range that can be used to communicate to the EC2 instances.
    Type: String
    MinLength: '9'
    MaxLength: '18'
    Default: 0.0.0.0/0
    AllowedPattern: (\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})/(\d{1,2})
    ConstraintDescription: must be a valid IP CIDR range of the form x.x.x.x/x.
  MyInstanceType:
    Description: Enter EC2 Type(Spec) Ex) t2.micro.
    Type: String
    Default: t3.xlarge
  LatestAmiId:
    Description: (DO NOT CHANGE)
    Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
    Default: '/aws/service/canonical/ubuntu/server/22.04/stable/current/amd64/hvm/ebs-gp2/ami-id'
    AllowedValues:
      - /aws/service/canonical/ubuntu/server/22.04/stable/current/amd64/hvm/ebs-gp2/ami-id

  TargetRegion:
    Type: String
    Default: ap-northeast-2
  AvailabilityZone1:
    Type: String
    Default: ap-northeast-2a
  AvailabilityZone2:
    Type: String
    Default: ap-northeast-2c

  VpcBlock:
    Type: String
    Default: 192.168.0.0/16
  PublicSubnet1Block:
    Type: String
    Default: 192.168.10.0/24
  PublicSubnet2Block:
    Type: String
    Default: 192.168.20.0/24

Resources:
# VPC
  IstioVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VpcBlock
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: Istio-VPC

# PublicSubnets
  PublicSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      AvailabilityZone: !Ref AvailabilityZone1
      CidrBlock: !Ref PublicSubnet1Block
      VpcId: !Ref IstioVPC
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: Istio-PublicSubnet1
  PublicSubnet2:
    Type: AWS::EC2::Subnet
    Properties:
      AvailabilityZone: !Ref AvailabilityZone2
      CidrBlock: !Ref PublicSubnet2Block
      VpcId: !Ref IstioVPC
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: Istio-PublicSubnet2

  InternetGateway:
    Type: AWS::EC2::InternetGateway
  VPCGatewayAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      InternetGatewayId: !Ref InternetGateway
      VpcId: !Ref IstioVPC

  PublicSubnetRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref IstioVPC
      Tags:
        - Key: Name
          Value: Istio-PublicSubnetRouteTable
  PublicSubnetRoute:
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref PublicSubnetRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway
  PublicSubnet1RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet1
      RouteTableId: !Ref PublicSubnetRouteTable
  PublicSubnet2RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet2
      RouteTableId: !Ref PublicSubnetRouteTable

# EC2 Hosts
  EC2SG:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Kans EC2 Security Group
      VpcId: !Ref IstioVPC
      Tags:
        - Key: Name
          Value: Istio-SG
      SecurityGroupIngress:
      - IpProtocol: '-1'
        CidrIp: !Ref SgIngressSshCidr
      - IpProtocol: '-1'
        CidrIp: !Ref VpcBlock
      - IpProtocol: '-1'
        CidrIp: 10.10.200.0/24
      - IpProtocol: '-1'
        CidrIp: 172.16.0.0/16
      - IpProtocol: tcp
        FromPort: 80
        ToPort: 80
        CidrIp: 0.0.0.0/0
      - IpProtocol: tcp
        FromPort: 8080
        ToPort: 8080
        CidrIp: 0.0.0.0/0
      - IpProtocol: tcp
        FromPort: 30000
        ToPort: 30000
        CidrIp: 0.0.0.0/0

  EC21:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !Ref MyInstanceType
      ImageId: !Ref LatestAmiId
      KeyName: !Ref KeyName
      Tags:
        - Key: Name
          Value: k3s-s
      NetworkInterfaces:
        - DeviceIndex: 0
          SubnetId: !Ref PublicSubnet1
          GroupSet:
          - !Ref EC2SG
          AssociatePublicIpAddress: true
          PrivateIpAddress: 192.168.10.10
      BlockDeviceMappings:
        - DeviceName: /dev/sda1
          Ebs:
            VolumeType: gp3
            VolumeSize: 30
            DeleteOnTermination: true
      UserData:
        Fn::Base64:
          !Sub |
            #!/bin/bash
            hostnamectl --static set-hostname k3s-s

            # Config convenience
            echo 'alias vi=vim' >> /etc/profile
            echo "sudo su -" >> /home/ubuntu/.bashrc
            ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime

            # Disable ufw & apparmor 
            systemctl stop ufw && systemctl disable ufw
            systemctl stop apparmor && systemctl disable apparmor

            # Install packages
            apt update && apt-get install bridge-utils net-tools conntrack ngrep jq tree unzip kubecolor -y

            # local dns - hosts file
            echo "192.168.10.10 k3s-s" >> /etc/hosts

            # Install k3s-server
            curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.28.15+k3s1 INSTALL_K3S_EXEC=" --disable=traefik"  sh -s - server --token istiotoken --cluster-cidr "172.16.0.0/16" --service-cidr "10.10.200.0/24" --write-kubeconfig-mode 644 

            # Change kubeconfig
            echo 'export KUBECONFIG=/etc/rancher/k3s/k3s.yaml' >> /etc/profile

            # Install Helm
            curl -s https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

            # Alias kubectl to k
            echo 'alias kc=kubecolor' >> /etc/profile
            echo 'alias k=kubectl' >> /etc/profile
            echo 'complete -o default -F __start_kubectl k' >> /etc/profile

            # kubectl Source the completion
            source <(kubectl completion bash)
            echo 'source <(kubectl completion bash)' >> /etc/profile
            
            # Install Kubectx & Kubens
            git clone https://github.com/ahmetb/kubectx /opt/kubectx
            ln -s /opt/kubectx/kubens /usr/local/bin/kubens
            ln -s /opt/kubectx/kubectx /usr/local/bin/kubectx

            # Install Kubeps & Setting PS1
            git clone https://github.com/jonmosco/kube-ps1.git /root/kube-ps1
            cat <<"EOT" >> ~/.bash_profile
            source /root/kube-ps1/kube-ps1.sh
            KUBE_PS1_SYMBOL_ENABLE=true
            function get_cluster_short() {
              echo "$1" | cut -d . -f1
            }
            KUBE_PS1_CLUSTER_FUNCTION=get_cluster_short
            KUBE_PS1_SUFFIX=') '
            PS1='$(kube_ps1)'$PS1
            EOT


  EC24:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.small
      ImageId: !Ref LatestAmiId
      KeyName: !Ref KeyName
      Tags:
        - Key: Name
          Value: forum-vm
      NetworkInterfaces:
        - DeviceIndex: 0
          SubnetId: !Ref PublicSubnet1
          GroupSet:
          - !Ref EC2SG
          AssociatePublicIpAddress: true
          PrivateIpAddress: 192.168.10.200
      BlockDeviceMappings:
        - DeviceName: /dev/sda1
          Ebs:
            VolumeType: gp3
            VolumeSize: 30
            DeleteOnTermination: true
      UserData:
        Fn::Base64:
          !Sub |
            #!/bin/bash
            hostnamectl --static set-hostname forum-vm

            # Config convenience
            echo 'alias vi=vim' >> /etc/profile
            echo "sudo su -" >> /home/ubuntu/.bashrc
            ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime

            # Disable ufw & apparmor 
            systemctl stop ufw && systemctl disable ufw
            systemctl stop apparmor && systemctl disable apparmor

            # Install packages
            apt update && apt-get install net-tools ngrep jq tree unzip apache2 -y

            # local dns - hosts file
            echo "192.168.10.200  forum-vm" >> /etc/hosts


Outputs:
  Serverhost:
    Value: !GetAtt EC21.PublicIp

 

CloudFormation 스택 배포 ← 실행하는 PC에 aws cli 설치되어 있고, aws configure 자격증명 설정 상태

# YAML 파일 다운로드
curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/istio-8w.yaml

# CloudFormation 스택 배포
# aws cloudformation deploy --template-file kans-7w.yaml --stack-name mylab --parameter-overrides KeyName=<My SSH Keyname> SgIngressSshCidr=<My Home Public IP Address>/32 --region ap-northeast-2
예시) aws cloudformation deploy --template-file istio-8w.yaml --stack-name mylab --parameter-overrides KeyName=kp-gasida SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 --region ap-northeast-2

## Tip. 인스턴스 타입 변경 : MyInstanceType=t3.xlarge (vCPU 4, Mem 16)
예시) aws cloudformation deploy --template-file istio-8w.yaml --stack-name mylab --parameter-overrides MyInstanceType=t3.xlarge KeyName=kp-gasida SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 --region ap-northeast-2

# CloudFormation 스택 배포 완료 후 작업용 EC2 IP 출력
aws cloudformation describe-stacks --stack-name mylab --query 'Stacks[*].Outputs[0].OutputValue' --output text --region ap-northeast-2

# [모니터링] CloudFormation 스택 상태 : 생성 완료 확인
while true; do 
  date
  AWS_PAGER="" aws cloudformation list-stacks \
    --stack-status-filter CREATE_IN_PROGRESS CREATE_COMPLETE CREATE_FAILED DELETE_IN_PROGRESS DELETE_FAILED \
    --query "StackSummaries[*].{StackName:StackName, StackStatus:StackStatus}" \
    --output table
  sleep 1
done

# 배포된 aws ec2 유동 공인 IP 확인
aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text
k3s-s   43.202.60.44    running
testpc  15.165.15.104   running

# EC2 SSH 접속 : 바로 접속하지 말고, 3~5분 정도 후에 접속 할 것
ssh -i ~/.ssh/kp-gasida.pem ubuntu@$(aws cloudformation describe-stacks --stack-name mylab --query 'Stacks[*].Outputs[0].OutputValue' --output text --region ap-northeast-2)
...
(⎈|default:N/A) root@k3s-s:~# <- kubeps 가 나오지 않을 경우 ssh logout 후 다시 ssh 접속 할 것!

 

 

k3s-s , forum-vm 각각 접속 후 확인

k3s-s 접속 후 확인 : ssh -i <> ubuntu@3.38.151.222

 

forum-vm 접속 후 확인 : ssh -i <> ubuntu@54.180.243.135

 

13.1 이스티오의 가상머신 지원

들어가며 : Istio’s VM support

• 가상머신을 메시에 통합하는 것은 이스티오 초기부터 지원됐지만, 제어 평면 외부에서 많은 해결책과 자동화가 필요했습니다.
• 이스티오의 가상머신 지원은 1.9.0에서 핵심 기능 일부가 구현되고 API가 적절한 접근법으로 결정되면서 베타 beta 로 승격됐다.
• 이때의 핵심 기능들이란 다음과 같다.
  • 가상머신에서의 사이드카 프록시 설치 및 설정. istioctl 로 간소화됐다.
  • 가상머신의 고가용성. 이스티오의 두 가지 새 리소스인 WorkloadGroup, WorkloadEntry 를 도입하면서 달성됐다.
  • 가상머신에서 메시 내 서비스의 DNS 해석. 이스티오의 사이드카와 함께 설정되는 로컬 DNS 프록시를 사용해서 가능해졌다.
• 이번 장에서는 다룰 정보가 많으므로 이런 새 기능들을 고수준에서 다루는 것부터 시작한다.
• 그런 다음, 가상머신을 메시에 통합해 구체적인 예제로 작동시킬 것이다.

 

13.1.1 가상머신에서의 사이드카 프록시 설치 및 설정 단순화하기 Simplifying sidecar proxy installation and configuration in a VM

들어가며

• 가상머신이 메시의 일부가 되려면 다음을 해야 한다.
  • 네트워크 트래픽을 관리할 사이드카 프록시 설치 Install the sidecar proxy to manage network traffic
  • 프록시가 istiod에 연결해 메시 설정을 받도록 설정 Configure the proxy to connect to istiod and receive the mesh configuration
  • istiod에 인증하는 데 사용할 ID 토큰을 가상머신에 제공 Provide the VM with an identity token, used to authenticate to istiod

 

그림 13.1은 워크로드가 메시의 일부가 되는 데 필요한 전제 조건을 보여준다.

 

• 쿠버네티스에서 실행되는 워크로드에도 같은 작업이 필요하다.
  • 웹훅 webhook 이나 istioctl 을 사용해 사이드카를 자동으로 설치하고 설정한다. Install and configure the sidecar automatically with the webhook or using istioctl.
  • ID 토큰을 소유한다. 쿠버네티스가 파드에 자동으로 주입한다. Possess an identity token—Kubernetes injects it automatically into the Pod.

 

• 이런 편의성은 쿠버네티스 외부의 워크로드로 확장되지 않는다. These conveniences do not extend to workloads external to Kubernetes.
• 그러므로 가상머신 소유자는 프록시를 설치하고 설정해야 하며, 워크로드 ID용 부트스트랩 토큰을 제공해야 한다. 그러나 나서야 워크로드가 메시의 일부가 될 수 있다. Thus VM owners must install and configure the proxy and provision a bootstrap token for workload identity and only then can a workload become a part of the mesh.

Single-network architecture

https://academy.tetrate.io/courses/take/istio-fundamentals/

• In a single-network scenario, the Kubernetes cluster and VM workloads share the same L3 network space. The VMs can reach Istiod (the control plane) and other Pods directly by IP. You may still choose to route the control-plane traffic through a gateway (such as the istio-ingressgateway), but it's not strictly required if direct connectivity is available.
• When using auto-registration, the VM will contact Istiod (or the gateway) on startup and automatically create a WorkloadEntry resource in the control plane, using a WorkloadGroup template you define in advance.

 

Multi-network architecture

• In a multi-network scenario, VM workloads reside in a different network than the Kubernetes cluster, so Pods cannot directly communicate with the VMs’ IP addresses. An Istio east-west gateway (or an ingress/egress gateway configured for cross-network traffic) bridges the networks.
• All traffic—including control-plane communication and data-plane traffic—flows through the gateway between the two networks. The VM must be configured with the gateway’s address so it can securely connect to Istiod and establish mTLS tunnels for application traffic.

 

가상머신의 프로비저닝 ID 자세히 살펴보기 A CLOSER LOOK AT PROVISIONING IDENTITY FOR VMS

• 이스티오는 가상머신에 ID를 제공하는 신뢰의 원천으로 쿠버네티스를 사용한다.
• 이는 쿠버네티스에서 토큰을 만들고 머신에 전달하면서 동작한다.
• 이 토큰은 머신에 설치된 istio-agent가 가져가 istiod에 인증하는 데 사용한다.
• 그림 13.2와 13.3은 클러스터 워크로드와 가상머신 워크로드에서 ID가 제공되는 방식의 차이를 보여준다.

클러스터의 워크로드는 (1) 서비스 어카운트 토큰을 파드에 주입받으며 (2) 그 토큰을 사용해 인증하고 SVID를 가져온다.

 

가상머신은 외부이기 때문에 수작업이 필요하다. (1) 서비스 어카운트를 만들고, (2) 그 토큰을 가상머신에 전달하며, (3) 그 토큰을 사용해 인증하고 SVID를 받는다.

• 쿠버네티스가 토큰을 자동으로 파드에 주입한다는 점만 빼면 접근법은 비슷하다.
• 반면 가상머신에서는 서비스 메시 운영자가 이 작업을 수행해야 하는데, 수작업으로 토큰을 안전하게 가상머신으로 전달해야 한다.
• istio-agent는 이 토큰을 사용해 istiod에 인증하고, 그 결과 istiod가 SVID 형태로 그 ID를 발급한다.
• 이 솔루션의 단점은 서비스 메시 운영자가 Kubernetes에서 토큰을 자동으로 생성하고 이를 VM으로 안전하게 전송해야 한다는 점입니다. The drawback of this solution is that it requires service mesh operators to automate creating the tokens in Kubernetes and securely transferring them to VMs.
• 이것은 많은 노력이 필요하지 않을 수도 있지만, 대부분의 조직이 다중 클라우드 전략을 따르는 경우 빠르게 많은 노력을 더하게 됩니다. This may not require a lot of effort, but if the organization follows a multi-cloud strategy, as most do, then it quickly adds up to a lot of effort.

(참고) 플랫폼이 할당한 ID Platform-assigned identity

• 이스티오 커뮤니티에서는 서로 다른 클라우드 프로바이더의 머신에 워크로드 ID를 자동으로 제공하는 해결책을 개발 중이다.
• 이 방법은 가상머신의 플랫폼이 부여한 ID를 신뢰의 근원으로 사용하며, istio-agent가 이를 갖고 istiod에 인증하는 데 사용한다.
• 당연히 이스티오는 토큰 검증을 설정하는 API를 클라우드 프로바이더에 노출할 것이다. 전체 과정은 아래 시각화 확인.

이 방법은 아직 개발되지 않았지만 ID 공급자 설계 문서를 참조 - Docs

 

• 다음 예제에서는 머신 ID를 프로비저닝하기 위한 신뢰의 원천으로 쿠버네티스를 사용한다. In our example that follows, we use Kubernetes as the source of trust to provision the identity of the machine.
• 간결하게 하기 위해 토큰은 수작업으로 가상머신에 전달할 것이다. To keep the chapter snappy, we’ll manually transfer the token to the VM.

 

13.1.2 가상머신 고가용성 Virtual machine high availability

들어가며

• 가상머신에서 고가용성을 달성하고자 이스티오는 쿠버네티스가 컨테이너화된 워크로드에서 취하는 접근법을 매우 흡사하게 모방한다.
• 기본적으로 쿠버네티스는 다음 리소스로 고가용성을 달성한다.
  • 디플로이먼트 Deployment : 고수준 리소스로, 복제본이 어떻게 만들어져야 하는지에 대한 설정을 담고 있다.
  • 파드 Pod : 위 설정으로 만든 복제본이다. 이렇게 하면 파드에 고유한 부분이 없다는 것이 보장되므로 파드가 정상이 아닐 때마다 폐기하고 갈아치울 수 있다(혹은 불필요 할 때 줄일 수 있다). 그렇게 서비스 가용성을 유지 가능하다.

• 이스티오가 가상머신에 도입하는 리소스는 쿠버네티스의 디플로이먼트 및 파드 개념과 흡사핟.
  • WorkloadGroup 리소스는 쿠버네티스의 디플로이먼트와 유사하다.
    • 관리하는 워크로드를 설정하는 방법에 대한 템플릿을 정의하기 때문이다. it defines the template for how the workloads it manages are configured.
    • 이 리소스는 공통 속성을 지정하는데, 여기서는 애플리케이션이 노출하는 포트, 그룹의 인스턴스에 부여하는 레이블, 메시에서 워크로드의 ID를 나타내는 서비스 어카운트, 애플리케이션 상태 프로브 Probe 방법 등이 있다.
  • WorkloadEntry 리소소는 쿠버네티스의 파드와 유사하다.
    • WorkloadEntry는 최종 사용자 트래픽을 처리하는 개별 가상머신을 나타낸다. It represents a single VM that serves end-user traffic.
    • WorkloadEntry는 WorkloadGroup에서 정의한 공통 속성 외에 인스턴스의 상태와 주소 등과 같은 고유한 속성도 갖고 있다.
• WorkloadEntry는 수동으로 생성할 수 있다. 그러나 권장하는 방식은 새로 뜬 워크로드가 메시에 자동으로 참가하는 워크로드 자동 등록을 이용하는 것이다. A WorkloadEntry can be created manually; however, the recommended approach is to use workload auto-registration, where newly provisioned workloads join the mesh automatically.

 

워크로드 자동 등록 이해하기 UNDERSTANDING WORKLOAD AUTO-REGISTRATION

• 워크로드를 자동 등록하는 동안, 워크로드는 제공받은 설정을 사용해 컨트롤 플레인에 연결하고 ID 토큰으로 자신이 WorkloadGroup의 일원임을 인증한다. During workload auto-registration, a workload connects to the control plane (using the configuration supplied to it) and authenticates itself as a member of a WorkloadGroup using the identity token.
• 이 작업이 성공하면 컨트롤 플레인은 메시에서 가상머신을 나타내는 WorkloadEntry를 생성한다 (그림 13.4 참조). When this is done successfully, the control plane creates a WorkloadEntry to represent the VM in the mesh.

워크로드 자동 등록 과정

• 메시 내의 가상머신을 WorkloadEntry로 표현하는 것은 여러 이유로 중요하다. The representation of the VM in the mesh using a WorkloadEntry is important for many reasons.
• 특히 쿠버네티스 서비스나 이스티오 ServiceEntry 리소스가 레이블 셀렉터로 워크로드를 선택해 트래픽을 라우팅할 백엔드로 사용할 수 있다. In particular, it can be selected by Kubernetes services or Istio ServiceEntry resources using label selectors and used as the backend to route traffic to.
• 실제 주소가 아니라 쿠버네티스 서비스(즉, 클러스터 내의 FQDN)로 워크로드를 선택하면, 클라이언트 측에 대한 별다른 지식이나 영향 없이도 정상적이지 않은 워크로드를 폐기하거나 늘어난 수요에 맞추기 위해 새 워크로드를 쉽게 띄울 수 있다. Selecting workloads using Kubernetes services (that is, their fully qualified domain name [FQDN] in the cluster) and not their actual addresses makes it possible to dispose of workloads when they are not healthy or easily spin up new ones to meet increased demand without any knowledge or impact on the client side.

 

• 그림 13.5는 어떻게 서비스를 사용해 WorkloadEntry와 파드를 겨냥할 수 있는지 보여준다. Figure 13.5 illustrates how services can be used to target workload entries and Pods.
• 예를 들어, 가상머신에서 실행하는 레거시 워크로드를 쿠버네티스에서 실행하는 현대화 워크로드로 (마이그레이션) 이전할 때 위험을 줄이려는 경우가 여기에 해당할 수 있다. You might want to do that to, for instance, reduce the risk when migrating from legacy workloads running in VMs to modernized workloads running in a Kubernetes cluster.
• 워크로드를 병렬로 실행한 다음, 서비스 메시의 트래픽 전환 기능을 사용해(5장에서 설명) 모든 트래픽을 가상머신에서 파드로 점차 옮긴다.
• 이 과정에서 오류가 늘어나면 트래픽을 가상머신으로 되돌릴 수 있는 선택지도 갖고 있는 것이다. This is done by running workloads in parallel and then using the traffic-shifting capabilities of the service mesh (as described in chapter 5) to gradually move all traffic from VMs to Pods, with the option of shifting traffic back to the VMs if there is an increase in errors.

Deployment와 Pod에 대비한 WorkloadGroup 과 WorkloadEntry의 관계

 

 

이스티오가 수행하는 헬스 체크 이해하기 UNDERSTANDING THE HEALTH CHECKS PERFORMED BY ISTIO

• 워크로드가 서비스 메시의 일부가 되고 나면, 트래픽을 받을 준비가 돼야 하며 헬스 체크로 검사받는다. After becoming part of the service mesh, a workload needs to be ready to receive traffic and is probed by health checks.
• 서비스의 고가용성을 유지하려면 두 가지 헬스 체크가 필요하다 (쿠버네티스가 헬스 체크하는 방식과 비슷하다). To maintain high availability of a service, we need two types of health checks (which are similar to how Kubernetes does health checking):
  • readiness 프로브는 워크로드가 시작된 후 트래픽을 수신할 준비가 됐는지 확인한다. Readiness probes check whether a workload is ready to receive traffic once it starts.
  • liveness 프로브는 애플리케이션이 실행 중일 때 정상인지 확인한다. 정상이 아니면 재시작해야 한다. Liveness probes check whether the application is healthy once it’s running; if not, it should be restarted.

• liveness 프로브는 서비스 메시의 관심사가 아니다! Liveness probes are not a service mesh concern!
• 워크로드가 살아 있는지 확인하는 것은 실행 중인 플랫폼의 기능이다. Ensuring the liveness of a workload is a platform feature where workloads are run.
• 예를 들어, 플랫폼인 쿠버네티스가 Deployment 설정에서 정의한 프로브로 liveness 를 검사한다. For example, Kubernetes, which is also a platform, performs liveness checks using the probes defined in the Deployment configuration.
• 마찬가지로 워크로드를 클라우드의 가상머신에서 실행할 때는 클라우드의 기능을 사용해 liveness 프로브를 구현하고, 프로브가 실패하면 새 인스턴스를 띄우는 등 복구하기 위한 수정 조치를 취해야 한다. Similarly, when running workloads on VMs in the cloud, we need to use the features of the cloud to implement liveness probes and take corrective actions to heal the VM if the probe fails, such as provisioning a new instance.
• 다음은 가장 인기 있는 세 클라우드 프로바이더의 liveness 검사 및 자동 복구에 대한 문서다. To get you started, here are the docs for liveness checks and auto-healing for the three most popular cloud providers:
  • Azure implements automatic instance repairs for VM scale sets - Docs
  • Amazon Web Services implements health checks for auto-scale group instances - Docs

Google Cloud Platform implements health checking and auto-healing for managed instance groups - Docs

 

이스티오가 가상머신에서 readiness 프로브를 구현하는 방법 HOW ISTIO PERFORMS READINESS PROBES IN VMS

• 애플리케이션이 트래픽을 받을 준비가 됐는지는 WorkloadGroup 정의에 명세된 바에 따라 istio-agent 가 주기적으로 검사한다. The application’s readiness to receive traffic is probed periodically by the istio-agent, according to the specification in the WorkloadGroup definition.
• 에이전트는 애플리케이션의 상태를 istiod에 보고하는데, 상태가 정상에서 비정상으로, 혹은 비정상에서 정상으로 바뀔 때 등이다 (그림 13.6) The agent reports the application’s health status to istiod, such as when the status switches from healthy to unhealthy or vice versa.

사이드카 프록시는 istiod를 애플리케이션 상태 정보로 업데이트한다.

• 컨트롤 플레인은 상태를 사용해 그 워크로드로 라우팅할지 여부를 결정한다. The control plane uses the health status to determine whether traffic should be routed to a workload.
• 예를 들어 애플리케이션이 정상이면 데이터 플레인에 애플리케이션을 호스팅하는 가상머신의 엔드포인트를 설정한다. For example, when the application is healthy, the data plane is configured with the endpoint of the VM that hosts the application.
• 그리고 그 반대도 마찬가지도. 애플리케이션이 비정상일 때 데이터플레인에서 엔드포인트를 제거한다. And the opposite is also true: the endpoint is removed from the data plane when the application is unhealthy.

• 서비스 메시 운영자는 WorkloadGroup에 애플리케이션 readiness 검사를 설정하고, 클라우드 프로바이더가 권장하는 방법에 따라 인프라 계층에 liveness 검사를 만들어야 한다. As a service mesh operator, you have to configure the readiness checks of the application in the WorkloadGroup and create liveness checks in the infrastructure layer by following your cloud provider’s recommended practices.
• liveness 와 readiness 프로브에는 다른 설정을 사용하는 것을 추천한다. We recommend using different configurations for liveness and readiness probes:
  • istio-agent 가 수행하는 readiness 프로브는 공격적이어야 하며 트래픽이 오류를 반환하는 인스턴스로 라우팅되는 것을 방지해야 한다. Readiness probes performed by the istio-agent should be aggressive and prevent traffic from being routed to an instance that is returning errors.
  • 클라우드 프로바이더가 수행하는 liveness 프로브는 좀 더 보수적이어야 하며 가상머신이 복구할 시간을 줘야 한다. Liveness probes performed by the cloud provider should be more conservative and allow the VM time to recover.

• 인스턴스를 너무 경솔하게 죽이지 않도록 하자. 인스턴스를 죽이면 유예 기간 grace period 없이 진행 중인 요청을 종료해 최종 사용자에게 실패를 보여주기 때문이다. Aim to avoid killing instances too hastily, which would terminate inflight requests without a grace period, causing end-user visible failures.
• 경험상 좋은 방법은 liveness 프로브보다 readiness 프로브가 항상 먼저 실패하는 것이다.

 

13.1.3 메시 내 서비스의 DNS 해석 DNS resolution of in-mesh services

가상머신은 쿠버네티스 클러스터 외부에 있으므로 쿠버네티스 내부 DNS 서버에 접근할 수 없다. Because VMs are external to the Kubernetes cluster, they lack access to its internal DNS server.

https://istio.io/latest/blog/2020/dns-proxy/

• 그 결과 가상머신은 클러스터 서비스의 호스트네임을 해석할 수 없다. As a result, VMs cannot resolve the hostnames for cluster services.
• 이를 해결하는 것이 가상머신을 서비스 메시에 통합하기 위한 마지막 단계다. Providing a solution to this is the last milestone to integrate VMs into the service mesh.

 

• 먼저 왜 DNS 해석이 필요한지 궁금할 수 있다. You may wonder why we need DNS resolution in the first place.
• 애플리케이션과 함께 배포되는 서비스 프록시는 트래픽을 모든 워크로드로 라우팅하는 설정을 갖고 있지 않은가? Doesn’t the service proxy, deployed along with the application, possess the configuration to route traffic to all workloads?
• 그렇다. 프록시는 트래픽을 어떻게 라우팅할지에 관한 설정을 갖고 있다. You’re correct: the proxy has the configuration for how to route traffic!
• 그러나 문제는 트래픽을 애플리케이션에서 꺼나 프록시로 가져오는 데 있다. However, the issue lies in getting the traffic out of the application and to the proxy.
• 이를 위한 전체 조건은 호스트네임이 해석되는 것이다. A precondition for that to happen is for the hostname to be resolved.
• 그렇지 않으면, 트래픽은 절대 애플리케이션을 떠나지 않으므로 엔보이 프록시로 리다이렉트될 수 없다. If it isn’t, the traffic never leaves the application and cannot be redirected to the Envoy proxy.
• 이 문제는 그림 13.7에 시각화돼 있다.

DNS 해석이 실패하므로 아웃바운드 트래픽은 절대 엔보이 프록시에 도달하지 않는다

 

앞서, 클러스터 호스트네임은 보통 모든 쿠버네티스 서비스를 설정해둔 프라이빗 private DNS 서버를 사용해 해석했다. Previously, cluster hostnames were commonly resolved using a private DNS server configured with all Kubernetes services.

https://istio.io/latest/blog/2020/dns-proxy/

• 가상머신은 DNS 쿼리를 보내는 네임서버로 이 프라이빗 DNS 서버를 사용하도록 설정돼 있다. (A 레코드 동적 추가/변경/삭제 구현 필요) The VMs were configured to use this as a nameserver to which they sent DNS queries.
• 쿠버네티스 내 워크로드의 동적인 성질 때문에 프라이빗 DNS 서버를 설정하는 과정은, 이런 변경 사항을 수신하고 DNS 서버를 동기화 상태로 유지하는 쿠버네티스 컨트롤러를 사용해 자동화돼야 했다. Due to the dynamic nature of workloads in Kubernetes, the process of configuring the private DNS server had to be automated using a Kubernetes controller that listens for these changes and keeps the DNS server synchronized.
• exteranl-dns가 정확히 그 작업을 수행하는 오픈소스 솔루션이다. https://github.com/kubernetes-sigs/external-dns external-dns is an open source solution that does exactly that.
• 그러나 이는 차선책이지 서비스 메시 사용자가 원하는 통합 솔루션은 아니다. However, that is a workaround and not an integrated solution that service mesh users would like.
• 이스티오 후속 버전(1.8 이상)은 istio-agent 사이드카에 로컬 DNS 프록시를 도입했는데, istiod가 이 프록시에 메시 내 서비스를 모두 설정해둔다 (그림 13.8 참조). Later versions of Istio (1.8 and onward) introduced a local DNS proxy to the istio-agent sidecar, which is configured with all in-mesh services by istiod (see figure 13.8).

 

DNS 쿼리는 해석을 위해 DNS 프록시로 리다이렉트되는데, DNS 프록시에는 istiod가 클러스터 내 서비스를 설정해둔다.

 

https://istio.io/latest/blog/2020/dns-proxy/

• DNS 프록시는 엔보이 프록시와 함께 이스티오 사이드카로 동작하며 애플리케이션의 DNS 쿼리를 처리하는데, 이 DNS 쿼리는 이스티오에서 일반적으로 트래픽을 포착하는 방법인 Iptable 규칙을 사용해 DNS 프록시로 리다이렉트된다. The DNS proxy runs in Istio’s sidecar alongside the Envoy proxy and handles DNS queries from the application, which are redirected to the DNS proxy using Iptable rules—the usual Istio traffic-capture approach.
• istio-cni 를 사용할 때는 이 과정이 살짝 다르다. This differs slightly when using istio-cni.
• DNS 프록시를 지속적으로 업데이트하고자 이스티오는 NDS Name Discovery Serivce 라는 새 API를 도입했다. To keep the DNS proxy continuously updated, Istio introduced a new API called the Name Discovery Service (NDS).
• NDS를 사용하면, 메시에 쿠버네티스 서비스나 이스티오 ServiceEntry가 추가될 때마다 컨트롤 플레인이 데이터 플레인에 새 DNS 항목을 동기화한다. With the NDS, the control plane synchronizes the data plane with new DNS entries whenever a Kubernetes service or Istio ServiceEntry is added to the mesh.
• 그러나 DNS 프록시는 가상머신에 국한되지 않는다. DNS 프록시를 사용하면 링크 처럼 여러 추가 기능을 사용 할 수 있다 - Blog

https://www.anyflow.net/sw-engineer/istio-dns-proxying

지금까지 고수준 개념과 그 개념의 목표를 살펴봤다. 다음으로는 가상머신을 서비스 메시에 통합하면서 실제로 실행해보자.

 

[추천]  Kubernetes CoreDNS​

[추천] Istio DNS proxy: 지연 개선, DNS 부하 감소Istio DNS proxy: 지연 개선, DNS 부하 감소​

 

13.2 인프라 준비하기 Setting up the infrastructure

구성 환경 : cool-store 애플리케이션 호스팅

• webapp 과 catalog 서비스는 쿠버네티스 클러스터에 배포한다.
• forum 서비스는 가상머신에 배포한다.
• 클러스터와 가상머신이 다른 네트워크에 있다는 것은 주목할 만하다
  • 가상머신에서 클러스터 서비스로 향햐는 트래픽을 리버스 프록시할 east-west 게이트웨이가 필요하기 때문이다.

 

13.2.1 서비스 메시 준비하기 Setting up the service mesh : istio, app (실습~)

istio 1.17.8 설치 - Docs , Install , profile  

# (옵션) kube-ops-view
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set service.main.type=NodePort,service.main.ports.http.nodePort=30007 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl get deploy,pod,svc,ep -n kube-system -l app.kubernetes.io/instance=kube-ops-view

## kube-ops-view 접속 URL 확인
echo -e "http://$(curl -s ipinfo.io/ip):30007/#scale=1.5"
echo -e "http://$(curl -s ipinfo.io/ip):30007/#scale=1.3"

# 소스코드 clone
git clone https://github.com/AcornPublishing/istio-in-action
tree istio-in-action/book-source-code-master -L 1

# istioctl 설치
export ISTIOV=1.17.8
echo 'export ISTIOV=1.17.8' >> /root/.bashrc

curl -s -L https://istio.io/downloadIstio | ISTIO_VERSION=$ISTIOV sh -
cp istio-$ISTIOV/bin/istioctl /usr/local/bin/istioctl
istioctl version --remote=false

# 클러스터와 가상머신이 다른 네트워크에 있으므로, 이스티오를 설치한 네임스페이스에 네트워크 정보 레이블을 지정해야 한다.
kubectl create namespace istio-system
kubectl label namespace istio-system topology.istio.io/network=west-network

# demo 프로파일 컨트롤 플레인 배포
cat istio-in-action/book-source-code-master/ch13/controlplane/cluster-in-west-network.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-controlplane
  namespace: istio-system
spec:
  profile: demo
  components:
    egressGateways:
    - name: istio-egressgateway
      enabled: false
  values:
    global:
      meshID: usmesh
      multiCluster:
        clusterName: west-cluster
      network: west-network

istioctl install -f istio-in-action/book-source-code-master/ch13/controlplane/cluster-in-west-network.yaml --set values.global.proxy.privileged=true -y


# 보조 도구 설치
kubectl apply -f istio-$ISTIOV/samples/addons
kubectl apply -f istio-$ISTIOV/samples/addons # nodePort 충돌 시 한번 더 입력


# 설치 확인 : istiod, istio-ingressgateway, crd 등
kubectl get istiooperators -n istio-system -o yaml
kubectl get all,svc,ep,sa,cm,secret,pdb -n istio-system
kubectl get cm -n istio-system istio -o yaml
kubectl get crd | grep istio.io | sort

# 실습을 위한 네임스페이스 설정
kubectl create ns istioinaction
kubectl label namespace istioinaction istio-injection=enabled
kubectl get ns --show-labels

# istio-ingressgateway 서비스 : NodePort 변경 및 nodeport 지정 변경 , externalTrafficPolicy 설정 (ClientIP 수집)
kubectl patch svc -n istio-system istio-ingressgateway -p '{"spec": {"type": "NodePort", "ports": [{"port": 80, "targetPort": 8080, "nodePort": 30000}]}}'
kubectl patch svc -n istio-system istio-ingressgateway -p '{"spec": {"type": "NodePort", "ports": [{"port": 443, "targetPort": 8443, "nodePort": 30005}]}}'
kubectl patch svc -n istio-system istio-ingressgateway -p '{"spec":{"externalTrafficPolicy": "Local"}}'
kc describe svc -n istio-system istio-ingressgateway

# NodePort 변경 및 nodeport 30001~30003으로 변경 : prometheus(30001), grafana(30002), kiali(30003), tracing(30004)
kubectl patch svc -n istio-system prometheus -p '{"spec": {"type": "NodePort", "ports": [{"port": 9090, "targetPort": 9090, "nodePort": 30001}]}}'
kubectl patch svc -n istio-system grafana -p '{"spec": {"type": "NodePort", "ports": [{"port": 3000, "targetPort": 3000, "nodePort": 30002}]}}'
kubectl patch svc -n istio-system kiali -p '{"spec": {"type": "NodePort", "ports": [{"port": 20001, "targetPort": 20001, "nodePort": 30003}]}}'
kubectl patch svc -n istio-system tracing -p '{"spec": {"type": "NodePort", "ports": [{"port": 80, "targetPort": 16686, "nodePort": 30004}]}}'

# Prometheus 접속 : envoy, istio 메트릭 확인
echo -e "http://$(curl -s ipinfo.io/ip):30001"

# Grafana 접속
echo -e "http://$(curl -s ipinfo.io/ip):30002"

# Kiali 접속 : NodePort
echo -e "http://$(curl -s ipinfo.io/ip):30003"

# tracing 접속 : 예거 트레이싱 대시보드
echo -e "http://$(curl -s ipinfo.io/ip):30004"

 

 

cool-store 서비스/gw/vs 배포 및 http 요청 확인

# cool-store 서비스/gw/vs 배포
kubectl -n istioinaction apply -f istio-in-action/book-source-code-master/ch12/webapp-deployment-svc.yaml
kubectl -n istioinaction apply -f istio-in-action/book-source-code-master/ch12/webapp-gw-vs.yaml
kubectl -n istioinaction apply -f istio-in-action/book-source-code-master/ch12/catalog.yaml

# 확인
kc get deploy,svc -n istioinaction
kc get gw,vs -n istioinaction

 

http 요청 확인

# k3s-s
curl -s -H "Host: webapp.istioinaction.io" http://192.168.10.10:30000/api/catalog/ | jq
curl -s -H "Host: webapp.istioinaction.io" http://192.168.10.10:30000/api/catalog/items/1 | jq

# [forum-vm] k8s cool-store 요청 시도 확인
APP_IP=43.201.47.208 # k8s-s 의 공인 IP
curl -s -H "Host: webapp.istioinaction.io" http://$APP_IP:30000/api/catalog/items/1 | jq
while true; do curl -s -H "Host: webapp.istioinaction.io" http://$APP_IP:30000/api/catalog/ ; echo; date; sleep 1; done

# [자신의 PC] k8s cool-store 요청 시도 확인
바로 위 [testpc]와 동일 요청

# [k8s-s] forum-vm web 요청 시도 확인
curl 192.168.10.200
curl 192.168.10.200 -I

VM_IP=15.165.15.104 # testpc 의 공인 IP
curl $VM_IP
curl $VM_IP -I

 

 

 

13.2.2 가상머신 프로비저닝 Provisioning the VM : Ubuntu, 공인 IP, SSH 접근, 애플리케이션 포트 8080 노출

 

 

13.3 가상머신까지 메시 확인

컨트롤 플레인 업데이트 Mesh expansion to VMs (실습~)

• 가상머신 통합 기능은 베타 단계이며 기본적으로 활성화돼 있지 않다. 그러므로 IstioOperator 정의를 사용해 이스티오 설치를 업데이트해야 한다 - Docs The features to integrate a VM are in the beta phase1 and not enabled by default. Hence we need to update the Istio installation using the following IstioOperator definition, which enables the following features:
• 이 IstioOperator 정의는 워크로드 자동 등록, 헬스 체크, DNS 쿼리를 캡처해 DNS 프록시로 리다이렉트하는 기능을 활성화한다. workload auto registration, health checks, capturing DNS queries, and redirecting those queries to the DNS proxy.
• 이 기능들은 가상머신을 메시로 통합하는 데 필요하다. These features, as covered earlier in this chapter, are required to integrate a VM into the mesh:

# 컨트롤 플레인 업데이트 Mesh expansion to VMs
cat istio-in-action/book-source-code-master/ch13/controlplane/cluster-in-west-network-with-vm-features.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-controlplane
  namespace: istio-system
spec:
  profile: demo
  components:
    egressGateways:
    - name: istio-egressgateway
      enabled: false
  meshConfig:
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true" # DNS 쿼리가 캡처돼 DNS 프록시로 리다이렉트된다
  values:
    pilot:
      env:
        PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION: true # 워크로드를 컨트롤 플레인에 자동 등록할 수 있다
        PILOT_ENABLE_WORKLOAD_ENTRY_HEALTHCHECKS: true # 가상머신 워크로드의 상태를 검사한다
    global:
      meshID: usmesh
      multiCluster:
        clusterName: west-cluster
      network: west-network

istioctl install -f istio-in-action/book-source-code-master/ch13/controlplane/cluster-in-west-network-with-vm-features.yaml --set values.global.proxy.privileged=true -y
kubectl patch svc istio-ingressgateway -n istio-system -p '{"spec": {"type": "NodePort"}}'

• 업데이트된 컨트롤 플레인은 DNS 해석을 위해 서비스 프록시가 DNS 쿼리를 포착해서 사이드카에 있는 로컬 DNS 프록시로 리다이텍트하도록 설정한다. The updated control plane configures the service proxies to capture DNS queries and redirect them to the local DNS proxy in the sidecar for resolution.
• 게다가 워크로드는 자동으로 등록할 수 있고 헬스 체크를 수행해 istiod에 보고할 수 있다. Furthermore, workloads can auto-register and perform and report health status to istiod.
• 이 기능들을 사용하려면 한 가지 조건이 더 있다. 가상머신은 istiod에 연결해 설정과 ID를 받아올 수 있어야 한다. There is one further condition for us to use those features: the VM must be able to connect to istiod and receive its configuration and identity.

 

 

13.3.1 istiod와 클러스터 서비스들은 가상머신에 노출하기* Exposing istiod and cluster services to the VM

• 가상머신이 메시의 일부분이 되려면 istiod에 통신을 하고 클러스터 서비스들과 커넥션을 시작할 수 있어야 한다. To become part of the mesh, the VM must be able to talk to istiod and initiate connections to the cluster services.
• 가상머신과 클러스터가 같은 네트워크에 있을 때는 기본적으로 동작한다. This works out of the box when the VM and the cluster are in the same network.
• 그렇지만 우리의 경우에는 별개의 네트워크에 있으므로 트래픽을 이스티오의 컨트롤 플레인이나 워크로드로 프록시해줄 east-west 게이트웨이가 필요하다. but in our case, they are in separate networks and require an east-west gateway to proxy the traffic to the Istio control plane or workloads.
• east-west 게이트웨이 설치해보자 - Docs

#
cat istio-in-action/book-source-code-master/ch13/gateways/cluster-east-west-gw.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-eastwestgateway
  namespace: istio-system
spec:
  profile: empty
  components:
    ingressGateways:
    - name: istio-eastwestgateway
      label:
        istio: eastwestgateway
        app: istio-eastwestgateway
        topology.istio.io/network: west-network
      enabled: true
      k8s:
        env:
        - name: ISTIO_META_ROUTER_MODE
          value: "sni-dnat"
        # The network to which traffic is routed
        - name: ISTIO_META_REQUESTED_NETWORK_VIEW
          value: west-network
        service:
          ports:
          - name: status-port
            port: 15021
            targetPort: 15021
          - name: mtls
            port: 15443
            targetPort: 15443
          - name: tcp-istiod
            port: 15012
            targetPort: 15012
          - name: tcp-webhook
            port: 15017
            targetPort: 15017  
  values:
    global:
      meshID: usmesh
      multiCluster:
        clusterName: west-cluster
      network: west-network

#
istioctl install -f istio-in-action/book-source-code-master/ch13/gateways/cluster-east-west-gw.yaml -y

#
kubectl get pod -n istio-system -l chart=gateways
NAME                                     READY   STATUS    RESTARTS   AGE
istio-eastwestgateway-86f6cb4699-nbhnp   1/1     Running   0          9m47s
istio-ingressgateway-7b7ccd6454-xmqgw    1/1     Running   0          22m

kubectl get svc -n istio-system -l istio.io/rev=default
NAME                    TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                                                                      AGE
istio-eastwestgateway   LoadBalancer   10.10.200.252   192.168.10.10   15021:32278/TCP,15443:31099/TCP,15012:31437/TCP,15017:32573/TCP              178m
istio-ingressgateway    NodePort       10.10.200.125   <none>          15021:31538/TCP,80:30000/TCP,443:30005/TCP,31400:31525/TCP,15443:30143/TCP   4h1m
istiod                  ClusterIP      10.10.200.111   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4h1m

kubectl get svc -n istio-system istio-eastwestgateway -o json | jq
...
      {
        "name": "status-port",
        "nodePort": 32278,
        "port": 15021,
        "protocol": "TCP",
        "targetPort": 15021
      },
      {
        "name": "mtls",
        "nodePort": 31099,
        "port": 15443,
        "protocol": "TCP",
        "targetPort": 15443
      },
      {
        "name": "tcp-istiod",
        "nodePort": 31437,
        "port": 15012,
        "protocol": "TCP",
        "targetPort": 15012
      },
      {
        "name": "tcp-webhook",
        "nodePort": 32573,
        "port": 15017,
        "protocol": "TCP",
        "targetPort": 15017
      }
...

kubectl get svc -n istio-system istiod -o json | jq
...
      {
        "name": "https-dns",
        "port": 15012,
        "protocol": "TCP",
        "targetPort": 15012
      },
      {
        "name": "https-webhook",
        "port": 443,
        "protocol": "TCP",
        "targetPort": 15017
      },
...

 

• 게이트웨이를 설치하면 가상머신이 클러스터 서비스와 istiod에 접근하는 데 필요한 포트를 노출할 수 있다. With the gateway installed, we can expose the needed ports for the VM to access cluster services and istiod.
• 그림 13.11은 가상머신이 istiod와 클러스터 서비스들에 연결할 수 있도록 노출된 포트를 보여준다. Figure 13.11 shows the exposed ports that enable the VM to connect to istiod and the cluster services.
• 먼저 가상머신에서 메시 내 서비스로 향하는 요청을 리버스 프록시해주는 다중 클러스터 상호 TLS 포트(15443)을 노출해보자. Let’s initially expose the multi-cluster mTLS port (15443) that reverse-proxies requests from the VM to the in-mesh services

#
cat istio-in-action/book-source-code-master/ch13/expose-services.yaml 
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: cross-network-gateway
  namespace: istio-system
spec:
  selector:
    istio: eastwestgateway
  servers:
    - port:
        number: 15443
        name: tls
        protocol: TLS
      tls:
        mode: AUTO_PASSTHROUGH
      hosts:
        - "*.local"

kubectl apply -f istio-in-action/book-source-code-master/ch13/expose-services.yaml 
kubectl get gw,vs -A
NAMESPACE       NAME                                                AGE
istio-system    gateway.networking.istio.io/cross-network-gateway   2m23s
istioinaction   gateway.networking.istio.io/coolstore-gateway       82m

NAMESPACE       NAME                                                       GATEWAYS                HOSTS                         AGE
istioinaction   virtualservice.networking.istio.io/webapp-virtualservice   ["coolstore-gateway"]   ["webapp.istioinaction.io"]   82m

다음으로는 트래픽을 허용하고 istiod로 라우팅하도록 Gateway 리소스와 VirtualService 리소스를 적용해 istiod 포트를 노출한다.

#
cat istio-in-action/book-source-code-master/ch13/expose-istiod.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istiod-gateway
spec:
  selector:
    istio: eastwestgateway
  servers:
    - port:
        name: tls-istiod
        number: 15012
        protocol: tls
      tls:
        mode: PASSTHROUGH        
      hosts:
        - "*"
    - port:
        name: tls-istiodwebhook
        number: 15017
        protocol: tls
      tls:
        mode: PASSTHROUGH          
      hosts:
        - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: istiod-vs
spec:
  hosts:
  - "*"
  gateways:
  - istiod-gateway
  tls:
  - match:
    - port: 15012
      sniHosts:
      - "*"
    route:
    - destination:
        host: istiod.istio-system.svc.cluster.local
        port:
          number: 15012
  - match:
    - port: 15017
      sniHosts:
      - "*"
    route:
    - destination:
        host: istiod.istio-system.svc.cluster.local
        port:
          number: 443

# 
kubectl apply -f istio-in-action/book-source-code-master/ch13/expose-istiod.yaml -n istio-system


# 13.3.2 실습 전 아래와 같이 gw,vs 리소스가 생성되어있는지 확인하자!
kc get gw,vs -A
NAMESPACE       NAME                                                AGE
istio-system    gateway.networking.istio.io/istiod-gateway          9s
istio-system    gateway.networking.istio.io/cross-network-gateway   4m40s
istioinaction   gateway.networking.istio.io/coolstore-gateway       84m

NAMESPACE       NAME                                                       GATEWAYS                HOSTS                         AGE
istio-system    virtualservice.networking.istio.io/istiod-vs               ["istiod-gateway"]      ["*"]                         9s
istioinaction   virtualservice.networking.istio.io/webapp-virtualservice   ["coolstore-gateway"]   ["webapp.istioinaction.io"]   84m

 

• 인프라를 만들고, 컨트롤 플레인을 업데이트하고, 프록시가 컨트롤 플레인에 통신할 수 있도록 준비하면서 가상머신을 서비스 메시에 통합하기 위해 먼 길을 걸어왔다.
• 이제 가상머신이 속해 있는 워크로드 그룹을 나타내는 WorkloadGroup 을 만드는 것만 남았다.

 

13.3.2 WorkloadGroup 으로 워크로드 그룹 나타내기* Representing a group of workloads with a WorkloadGroup

• WorkloadGroup은 구성원인 가상머신들의 공통 속성을 정의하는데, 여기서는 노출할 포트, 애플리케이션이 트래픽을 받을 준비가 됐는지 테스트할 방법 같은 애플리케이션 전용 정보 등이 있다.
• 예를 들어 forum 워크로드의 공통 속성은 다음 WorkloadGroup에서 정의한다.

#
cat istio-in-action/book-source-code-master/ch13/workloadgroup.yaml
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
  name: forum
  namespace: forum-services
spec:
  metadata:
    annotations: {}
    labels:
      app: forum # 서비스는 레이블을 사용해 이 그룹의 워크로드를 대상으로 삼을 수 있다
  template:
    serviceAccount: forum-sa # 워크로드가 이 워크로드 그룹에 등록하려면 forum-sa 인증 토큰을 보유하고 있어야 한다
    network: vm-network # 이스티오가 동일한 네트워크에 있는 워크로드 사이의 직접 접근을 설정할 수 있도록 한다
  probe: # 이 워크로드 그룹의 인스턴스에서 실행되는 istio-agent는 HTTP GET 요청을 8080 포트의 /api/healthz 경로로 보내 앱의 준비 상태를 확인한다
    periodSeconds: 5
    initialDelaySeconds: 1
    httpGet:
      port: 8080
      path: /api/healthz

• 가상머신을 서비스 메시에 통합하기 위한 관련 속성 일부는 다음과 같다.
  • lables
    • 쿠버네티스 서비스들이 이 워크로드 그룹으로 등록된 워크로드 엔트리를 선택할 수 있게 해준다. Enables Kubernetes services to select the workload entries that register to this WorkloadGroup
  • network
    • 컨트롤 플레인이 이 속성을 사용해 트래픽을 가상머신으로 라우팅하도록 서비스 프록시를 설정한다. Using this property, the control plane configures service proxies to route traffic to the VM
    • 같은 네트워크에 있으면 IP 주소를 사용한다. 다른 네트워크라면 그 네트워크에 배포된 east-west 게이트웨이를 사용한다. if it’s the same network, use the IP address; otherwise, use the east-west gateway deployed in that network.
  • serviceAccount
    • 워크로드의 ID를 나타낸다. 워크로드가 이 그룹의 멤버로 등록하려면, 이 서비스 어카운트 ID용 클레임을 제시해야 한다. Represents the identity of the workloads. For a workload to register as a member of this group, it must represent a claim for the service account identity.

네임스페이스와 서비스 어카운트를 만들고 WorkloadGroup 설정을 클러스터에 적용해보자.

#
cat istio-in-action/book-source-code-master/ch13/workloadgroup.yaml
kubectl create namespace forum-services
kubectl create serviceaccount forum-sa -n forum-services
kubectl apply -f istio-in-action/book-source-code-master/ch13/workloadgroup.yaml

#
kubectl get-all -n forum-services
kubectl get workloadgroup -n forum-services
NAME    AGE
forum   2m2s

 

• WorkloadGroup 을 적용하고 나서 무슨 일이 일어날까?
• 이제 클러스터는 WorkloadGroup에 명세된 forum-sa 서비스 어카운트의 유효한 토큰을 제시할 수 있는 워크로드를 자동으로 등록하도록 설정된다.

 

가상머신의 사이드카용 설정 생성하기 GENERATING THE CONFIGURATION FOR THE VM’S SIDECAR

• WorkloadGroup 은 워크로드 자동 등록을 가능하게 하는 것 외에, 이 그룹에 있는 가상머신을 위한 공통 설정을 생성하는 데도 사용할 수 있다.
• istioctl 을 사용하면 가상머신 설정을 만드는 것이 매우 간단하다.
• istioctl 은 WorkloadGroup 안의 정보를 사용하고, WorkloadGroup 인스턴스용 설정을 생성하는 데 필요한 추가 정보는 쿠버네티스 클러스터에 쿼리한다.
• 예를 들어 다음 명령어는 forum 워크로드를 호스팅하는 머신용 설정을 생성한다.

# Generates all the required configuration files for workload instance on a VM or non-Kubernetes environment from a WorkloadGroup artifact.
#istioctl x workload entry configure -h
#istioctl x workload entry configure \
#--name forum \ # forum-services 네임스페이스에 있는 forum WorkloadGroup 을 읽고 워크로드 설정을 생성한다
#--namespace forum-services \ # 상동
#--clusterID "west-cluster" \ # 반드시 이스티오 설치 시 지정한 클러스터 이름으로 설정해야 한다
#--externalIP $VM_IP \ # 워크로드가 클러스터와 동일한 네트워크에 있지 않은 경우 workloadIP 파라미터가 필요하다. 디폴트 설정에 의하면, 정의하지 않은 경우 네트워크에서 할당한 사설 IP를 사용한다.
#--autoregister \ # 워크로드를 자동으로 등록하도록 설정한다.
#-o /tmp/my-workload-files/ # 설정 파일을 저장할 디렉터리 위치를 명령 실행 위치에 대한 상대 경로로 지정한다.

#
istioctl x workload entry configure -f istio-in-action/book-source-code-master/ch13/workloadgroup.yaml -o /tmp/my-workload-files/ --clusterID "west-cluster" --autoregister
cat /tmp/my-workload-files/hosts
192.168.10.10 istiod.istio-system.svc

chown ubuntu:ubuntu -R /tmp/my-workload-files/
tree /tmp/my-workload-files/
├── cluster.env
├── hosts
├── istio-token
├── mesh.yaml
└── root-cert.pem

• 정말 쉽다! 생성된 설정을 살펴보면 다양한 구성 요소가 동작 중임을 확인할 수 있다. 이 모든 것을 완벽히 이해할 필요는 없다.
• 그렇지만 이해하고 있다면, 마주칠 문제를 해결하는 데 도움이 될 것이다. 그런 이유로 부록 E에서 이 설정을 자세히 설명한다.
• 고수준에서 알아야 할 중요한 사실은 파일에 다음이 포함돼 있다는 점이다.
  • east-west 게이트웨이 IP 주소. 여기를 통해 istiod가 노출된다. The east-west gateway IP address through which istiod is exposed.
  • 루트 인증서. istiod가 제시한 인증서의 진위를 검증하는 데 사용한다. The root certificate to validate the authenticity of the certificate presented by istiod.
    • 인증서 검증은 서비스 프록시와 istiod 사이의 보안 커넥션을 시작하기 전에 수행해야 하는 선행 작업이다. It’s a precursor to initiating a secure connection between the service proxy and istiod.
  • 서비스 어카운트 토큰. istiod에게 forum WorkloadGroup의 구성원임을 인증하는 데 사용한다. The service account token to authenticate as a member of the forum WorkloadGroup, to istiod.
  • 서비스 메시. 네트워크, 공통 속성에 대한 설정. WorkloadGroup에 정의된 대로다. Configuration about the service mesh, the network, and the common properties, as defined in the WorkloadGroup.
• 이 설정이 있으면 서비스 프록시는 컨트롤 플레인에 보안 커넥션을 시작하고, 자신의 SVID를 가져오고, xDS로 엔보이 설정을 수신해 메시의 구성원이 될 수 있다. In the presence of this configuration, the service proxy can start a secure connection to the control plane, get its SVID, and receive its Envoy configuration via xDS to become a member of the mesh.

 

생성된 파일을 가상머신을 전송하기 TRANSFERRING THE GENERATED FILES TO THE VM

• 설정 파일에는 민감 정보(구체적으로는 서비스 어카운트 토큰)가 포함돼 있으므로 가상머신으로 안전하게 전송해야 한다.
• 시연을 위해 공수가 제일 적은 방법을 사용해 파일을 SSH를 통해 복사할 것이다.
• 이 방법은 안전하지만, 운영 환경에서는 당연히 이 과정이 자동화돼 수작업이 필요 없어야 한다.

# 임시로, 자신의 로컬 PC에 위 파일들 복사 : 바로 vm_ip 에 복사해도 되지만, 현재 실습 환경 편리성으로 경유 복사.
APP_IP=43.201.47.208
mkdir my-workload-files
scp -i ~/nowon9159 ubuntu@$APP_IP:/tmp/my-workload-files/\* ./my-workload-files # macOS
scp -i ~/nowon9159 ubuntu@$APP_IP:/tmp/my-workload-files/*  ./my-workload-files # linux

ls -al
openssl x509 -in ./my-workload-files/root-cert.pem -noout -text # istio CA 인증서
jwt decode $(cat ./my-workload-files/istio-token) # 토큰
...
Token claims
------------
{
  "aud": [
    "istio-ca"
  ],
  "exp": 1748083668,
  "iat": 1748080068,
  "iss": "https://kubernetes.default.svc.cluster.local",
  "kubernetes.io": {
    "namespace": "forum-services",
    "serviceaccount": {
      "name": "forum-sa",
      "uid": "64ab40b3-3bad-49f1-a1c9-0464d72c18c1"
    }
  },
  "nbf": 1748080068,
  "sub": "system:serviceaccount:forum-services:forum-sa"
}

cat ./my-workload-files/mesh.yaml
defaultConfig:
  discoveryAddress: istiod.istio-system.svc:15012
  meshId: usmesh
  proxyMetadata:
    CANONICAL_REVISION: latest
    CANONICAL_SERVICE: forum
    ISTIO_META_AUTO_REGISTER_GROUP: forum
    ISTIO_META_CLUSTER_ID: west-cluster
    ISTIO_META_DNS_CAPTURE: "true"
    ISTIO_META_MESH_ID: usmesh
    ISTIO_META_NETWORK: vm-network
    ISTIO_META_WORKLOAD_NAME: forum
    ISTIO_METAJSON_LABELS: '{"app":"forum","service.istio.io/canonical-name":"forum","service.istio.io/canonical-revision":"latest"}'
    POD_NAMESPACE: forum-services
    SERVICE_ACCOUNT: forum-sa
    TRUST_DOMAIN: cluster.local
  readinessProbe:
    httpGet:
      path: /api/healthz
      port: 8080
    initialDelaySeconds: 1
    periodSeconds: 5
  tracing:
    zipkin:
      address: zipkin.istio-system:9411


# 로컬 PC의 파일들을 forum-vm로 복사
FORUM=13.125.155.11
scp -i ~/nowon9159.pem ./my-workload-files/cluster.env ubuntu@$FORUM:/tmp/
scp -i ~/nowon9159.pem ./my-workload-files/istio-token ubuntu@$FORUM:/tmp/
scp -i ~/nowon9159.pem ./my-workload-files/mesh.yaml ubuntu@$FORUM:/tmp/
scp -i ~/nowon9159.pem ./my-workload-files/root-cert.pem ubuntu@$FORUM:/tmp/


# forum-vm 에서 파일 확인
ls -l /tmp
-rwxr--r-- 1 ubuntu ubuntu  714 May 24 19:08 cluster.env
-rwxr--r-- 1 ubuntu ubuntu  844 May 24 19:08 istio-token
-rwxr--r-- 1 ubuntu ubuntu  792 May 24 19:08 mesh.yaml
-rwxr--r-- 1 ubuntu ubuntu 1094 May 24 19:08 root-cert.pem
...

 

이제 파일이 가상머신으로 복사됐으므로, 사이드카가 서비스 메시에 참가하도록 설치하고 설정할 준비가 됐다.

 

13.3.3 가상머신에 istio-agent 설치 및 설정하기* Installing and configuring the istio-agent in the VM

forum-vm 가상머신에 istio-agent 를 다운로드하고 설치하자

#
cat /etc/resolv.conf
nameserver 127.0.0.53
...

ss -tnlp
State      Recv-Q     Send-Q         Local Address:Port         Peer Address:Port    Process
LISTEN     0          4096           127.0.0.53%lo:53                0.0.0.0:*        users:(("systemd-resolve",pid=357,fd=14))

ss -unlp
State     Recv-Q    Send-Q           Local Address:Port         Peer Address:Port    Process
UNCONN    0         0                127.0.0.53%lo:53                0.0.0.0:*        users:(("systemd-resolve",pid=357,fd=13))

resolvectl status
...
resolv.conf mode: stub # stub 모드로 설정, 127.0.0.53(local stub resolver)을 가리키며, systemd-resolved가 이 요청을 처리함

Link 2 (ens5)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.0.2
...

#
iptables -t nat -L -n -v
iptables -t filter -L -n -v
iptables -t mangle -L -n -v
iptables -t raw -L -n -v


# 데비안 패키지 형식으로 다운로드 후 설치
curl -LO https://storage.googleapis.com/istio-release/releases/1.17.8/deb/istio-sidecar.deb
file istio-sidecar.deb
dpkg -i istio-sidecar.deb
which pilot-agent
pilot-agent version
which envoy
envoy --version

tree /etc/istio
/etc/istio
├── config
│   └── mesh
├── envoy
│   ├── cluster.env
│   ├── envoy_bootstrap_tmpl.json
│   └── sidecar.env
├── extensions
│   ├── metadata-exchange-filter.compiled.wasm
│   ├── metadata-exchange-filter.wasm
│   ├── stats-filter.compiled.wasm
│   └── stats-filter.wasm
└── proxy

tree /var/lib/istio/
/var/lib/istio/
├── config
│   └── mesh
├── envoy
│   ├── envoy_bootstrap_tmpl.json
│   └── sidecar.env
├── extensions
│   ├── metadata-exchange-filter.compiled.wasm
│   ├── metadata-exchange-filter.wasm
│   ├── stats-filter.compiled.wasm
│   └── stats-filter.wasm
└── proxy

# istio-agent 는 특정 위치에서 설정 파일을 읽으므로, 복사해둔 파일을 옮겨보자
mkdir -p /etc/certs
mkdir -p /var/run/secrets/tokens

cp /tmp/root-cert.pem /etc/certs/root-cert.pem
cp /tmp/istio-token /var/run/secrets/tokens/istio-token
cp /tmp/cluster.env /var/lib/istio/envoy/cluster.env
cp /tmp/mesh.yaml /etc/istio/config/mesh


# istiod.istio-system.svc 요청을 istiod 인스턴스로 프록시하는 east-weat 게이트웨이 IP 주소로 정적으로 해석하도록 한다.
cat /etc/hosts
echo "192.168.10.10 istiod.istio-system.svc" | sudo sh -c 'cat >> /etc/hosts'
cat /etc/hosts

# istio-agent가 호스트네임 해석을 방해하지 않도록 hosts 파일에 forum-vm 머신의 호스트네임을 하드코딩하자 : 설정되어 있음
echo "$(hostname --all-ip-addresses | cut -d ' ' -f 1) $(hostname)" | sudo sh -c 'cat >> /etc/hosts'
cat /etc/hosts

• DNS 프록시가 클러스터 내 호스트네임을 해석해야 하는 것 아닌가? Shouldn’t the DNS proxy resolve the in-cluster hostnames?
  • 그렇다. 하지만 이 시점에서 사이드카가 아직 컨트롤 플레인에 연결되지 않았다면 파일럿이 알고 있는 DNS 항목이 없을 것이다.
  • 또한 /etc/hosts 에 east-west 게이트웨이 호스트네임을 정적으로 정의하는 것이 독자의 환경에 적합하지 않다면, east-west 게이트웨이를 가리키는 네트워크 로드 밸런서를 설치할 수 있다.
  • 네트워크 로드 밸런서를 설정하고 노출하는 방법은 자신의 클라우드 혹은 온프레미스 환경에 따라 참조하길 바란다.

에이전트를 시작하기 전 마지막 단계는 에이전트가 읽고 쓸 디렉터리에 소유자 권한을 부여하는 것이다.

#
cat /etc/passwd | tail -n 3
ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash
lxd:x:999:100::/var/snap/lxd/common/lxd:/bin/false
istio-proxy:x:998:999::/var/lib/istio:/bin/sh

tree /etc/istio
chown -R istio-proxy /var/lib/istio /etc/certs /etc/istio/proxy /etc/istio/config /var/run/secrets /etc/certs/root-cert.pem

#
systemctl status istio
systemctl start istio
systemctl enable istio
systemctl status istio
...
     CGroup: /system.slice/istio.service
             ├─32047 sudo -E -u istio-proxy -s /bin/bash -c "ulimit -n 1024; INSTANCE_IP=15.165.15.104 POD_NAME=testpc POD_NAMESPACE=forum-services >
             ├─32140 /usr/local/bin/pilot-agent proxy
             └─32148 /usr/local/bin/envoy -c etc/istio/proxy/envoy-rev.json --drain-time-s 45 --drain-strategy immediate --local-address-ip-version >

May 24 20:10:05 testpc istio-start.sh[32128]: -A ISTIO_OUTPUT -o lo -p tcp -m tcp ! --dport 53 -m owner ! --gid-owner 998 -j RETURN
May 24 20:10:05 testpc istio-start.sh[32128]: -A ISTIO_OUTPUT -m owner --gid-owner 998 -j RETURN
May 24 20:10:05 testpc istio-start.sh[32128]: -A ISTIO_OUTPUT -d 127.0.0.53/3cat 2 -p tcp -m tcp --dport 53 -j REDIRECT --to-ports 15053
May 24 20:10:05 testpc istio-start.sh[32128]: -A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
May 24 20:10:05 testpc istio-start.sh[32128]: -A ISTIO_OUTPUT -j ISTIO_REDIRECT
May 24 20:10:05 testpc istio-start.sh[32128]: -A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001
May 24 20:10:05 testpc istio-start.sh[32128]: COMMIT
May 24 20:10:05 testpc istio-start.sh[32128]: # Completed on Sat May 24 20:10:05 2025
May 24 20:10:05 testpc sudo[32047]:     root : PWD=/ ; USER=istio-proxy ; COMMAND=/bin/bash -c '\\/bin\\/bash -c ulimit\\ -n\\ 1024\\;\\ INSTANCE_IP>
May 24 20:10:05 testpc sudo[32047]: pam_unix(sudo:session): session opened for user istio-proxy(uid=998) by (uid=0)
...
## 혹은
journalctl -u istio -f
...

which istio-start.sh
cat /usr/local/bin/istio-start.sh


#
tree /etc/certs/
├── cert-chain.pem
├── key.pem
└── root-cert.pem

#
ps aux |grep istio

#
iptables -t nat -L -n -v
iptables -t filter -L -n -v
iptables -t mangle -L -n -v
iptables -t raw -L -n -v

에이전트 로그 확인하기 CHECKING THE AGENT LOGS

• 이스티오의 에이전트 로그는 다음 두 위치에 기록된다.
  • standard output 표준 출력 채널은 /var/log/istio/istio.log 파일에 쓰여진다
  • standard error 표준 오류 채널은 /var/log/istio/istio.err 파일에 쓰여진다
• 표준 출력 로그를 확인하면 이스티오 컨트롤 플레인으로의 연결이 성공했는지 알 수 있다

#
cat /var/log/istio/istio.log | grep xdsproxy
2025-05-25T01:09:42.094214Z	info	xdsproxy	Initializing with upstream address "istiod.istio-system.svc:15012" and cluster "west-cluster"
2025-05-25T01:09:42.227661Z	info	xdsproxy	connected to upstream XDS server: istiod.istio-system.svc:15012

# 만약 로그 파일이 생성되지 않았다면? 서비스 시작이 실패한 경우에 그럴 수 있다. 아래 처럼 systemd 로그를 확인하자
journalctl -u istio -f

 

워크로드가 메시에 등록됐는지 확인하기 VERIFYING THAT THE WORKLOAD REGISTERED TO THE MESH

워크로드 자동 등록이 활성화돼 있으면, 머신의 istio-agent 가 istiod 에 연결되자마자 WorkloadEntry 가 생성된다.

#
kubectl get workloadentries -n forum-services
NAME                              AGE    ADDRESS
forum-192.168.10.200-vm-network   110m   192.168.10.200

kc get workloadentries -n forum-services -o yaml
...
  status:
    conditions:
    - lastProbeTime: "2025-05-25T02:35:47.436392452Z"
      lastTransitionTime: "2025-05-25T02:35:47.436392780Z"
      message: 'Get "http://192.168.10.200:8080/api/healthz": dial tcp 127.0.0.6:0->192.168.10.200:8080:
        connect: connection refused'
      status: "False"
      type: Healthy
...

istioctl proxy-status
NAME                                                    CLUSTER          CDS        LDS        EDS        RDS          ECDS         ISTIOD                     VERSION
forum-vm.forum-services                                 west-cluster     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-d6549b9fc-rpg7l     1.17.0
webapp-684c568c59-9wtbt.istioinaction                   west-cluster     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-d6549b9fc-rpg7l     1.17.8
...

• 예상대로 가상머신의 WorkloadEntry 가 등록됐음을 확인할 수 있다. 또한 커넥션을 맺을 수 있는 주소도 표시된다.
• 이것들은 이 항목이 나타내는 가상머신만의 고유한 속성이다.
• 다음으로는 트래픽이 어떻게 클러스터 내 서비스로 라우팅되는지(그리고 그 반대도)를 살펴보자.

 

13.3.4 클러스터 서비스로 트래픽 라우팅하기 Routing traffic to cluster services

트래픽이 클러스터 서비스로 라우팅되는지 확인하기 위해 가상머신에서 webapp 워크로드로 curl 요청을 보내보자

# [forum-vm] 신규 터미널 : 패킷 모니터링 https://github.com/gcla/termshark/blob/master/docs/UserGuide.md
tcpdump -i any -w - udp port 53 | termshark
## CTRL+C 로 취소 후 수집된 패킷이 termshark 에서 확인 가능

# [forum-vm] : 도메인 해석은 잘 됨
dig +short webapp.istioinaction
10.10.200.48

curl -s webapp.istioinaction/api/catalog/items/1 | jq
watch curl -s webapp.istioinaction/api/catalog/items/1

# 신규 터미널 : 15443 연결하는 envoy 프로세스(데이터 플래인) 확인!
watch -d ss -tnp 
watch -d 'ss -tnp | grep envoy'
State     Recv-Q  Send-Q   Local Address:Port     Peer Address:Port  Process                                                   
ESTAB 0      0      192.168.10.200:41238 192.168.10.10:15443 users:(("envoy",pid=3203,fd=40))
ESTAB 0      0      192.168.10.200:41242 192.168.10.10:15443 users:(("envoy",pid=3203,fd=41))
...

# 신규 터미널 : 
watch -d iptables -t nat -L -n -v
watch -d iptables -t raw -L -n -v


# k3s-s
kubectl get svc,ep -n istioinaction webapp
NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/webapp   ClusterIP   10.10.200.48   <none>        80/TCP    148m

NAME               ENDPOINTS         AGE
endpoints/webapp   172.16.0.8:8080   148m

가상머신에서 요청한 트래픽이 클러스터 서비스에 도달하는 과정

1. 트래픽이 애플리케이션을 떠나려면 먼저 그 호스트네임을 해석해야 한다. 즉, DNS 쿼리가 DNS 프록시로 리다이렉트돼야 한다.
2. 이름이 IP 주소로 해석되면 애플리케이션은 아웃바운드 요청을 시작할 수 있다. 이 요청은 Iptables 규칙이 엔보이 프록시로 리다이렉트한다.
3. 엔보이 프록시는 트래픽을 east-west 게이트웨이로 라우팅한다.
4. east-west 게이트웨이는 요청을 webapp 으로 프록시하고, webapp은 catalog 서비스에 아이템을 쿼리한다.

 

• 이 과정을 고수준에서 살펴보면 ‘DNS 프록시는 어떻게 설정되는가?’와 ‘애플리케이션은 DNS 프록시와 어떻게 상호작용하는가?’ 같은 질문에 답할 수 있으며, 트래픽을 가상머신 워크로드에서 클러스터 서비스로 라우팅하는 전체 과정과 어떻게 연관되는지 이해할 수 있다.
• 서비스 메시 사용자로서는 이만하면 충분하지만, 궁금하다면 13.4절에서 자세한 정보를 찾아볼 수 있다.

 

(옵션) 자신의 PC에서 webapp 반복 접속 후 확인

while true; do curl -s -H "Host: webapp.istioinaction.io" http://$APP_IP:30000/api/catalog/ ; echo; date; sleep 1; done

13.3.5 트래픽을 WorkloadEntry로 라우팅하기 Routing traffic to the WorkloadEntry

• 앞 절에서는 머신에서 클러스터 내부/메시 내부 서비스로의 라우팅을 확인해봤다. 이제 그 반대로 라우팅하는 것을 확인해보자.
• 즉, 클러스터 안에서 가상머신 워크로드로 라우팅할 것이다.
• 가상머신에서 실행 중인 서비스로 도달하려면 어떻게 요청을 보내야 할까? WorkloadEntry에서 본 IP 주소를 써야 할까? 당연히 아니다.
• 쿠버네티스에서 파드의 IP 주소를 사용하지 않는 것처럼, 플랫폼을 유연하게 유지하고 인스턴스를 교체할 수 있게 하기 위함이다.
• 앞서 간단히 언급했듯이 쿠버네티스 서비스를 만들어야 한다.
• 쿠버네티스 서비스는 인스턴스를 레이블로 고르며, 이스티오가 모든 서비스를 올바른 IP 주소로 동적으로 설정할 수 있다.
• 예를 들어 forum WorkloadEntry를 고르려면 다음과 같은 쿠버네티스 서비스를 사용한다.

#
cat istio-in-action/book-source-code-master/services/forum/kubernetes/forum-svc.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    app: forum
  name: forum
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: forum

kubectl apply -f istio-in-action/book-source-code-master/services/forum/kubernetes/forum-svc.yaml -n forum-services

kubectl get svc,ep -n forum-services
NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/forum   ClusterIP   10.10.200.72   <none>        80/TCP    20s

NAME              ENDPOINTS   AGE
endpoints/forum   <none>      20s

#
istioctl proxy-config route deploy/webapp.istioinaction
istioctl proxy-config route deploy/webapp.istioinaction --name 80 -o json
...
      "name": "forum.forum-services.svc.cluster.local:80",
      "domains": [
          "forum.forum-services.svc.cluster.local",
          "forum.forum-services",
          "forum.forum-services.svc",
          "10.10.200.72"
      ],
      "routes": [
          {
              "name": "default",
              "match": {
                  "prefix": "/"
              },
              "route": {
                  "cluster": "outbound|80||forum.forum-services.svc.cluster.local",
...

#
istioctl proxy-config cluster deploy/webapp.istioinaction
istioctl proxy-config cluster deploy/webapp.istioinaction --fqdn forum.forum-services.svc.cluster.local -o json
istioctl proxy-config cluster deploy/webapp.istioinaction --fqdn forum.forum-services.svc.cluster.local
SERVICE FQDN                               PORT     SUBSET     DIRECTION     TYPE     DESTINATION RULE
forum.forum-services.svc.cluster.local     80       -          outbound      EDS   

# 아직 없다!
istioctl proxy-config endpoint deploy/webapp.istioinaction
istioctl proxy-config endpoint deploy/webapp.istioinaction | grep forum

#
istioctl proxy-config listener deploy/istio-eastwestgateway.istio-system
istioctl proxy-config route deploy/istio-eastwestgateway.istio-system
istioctl proxy-config cluster deploy/istio-eastwestgateway.istio-system
istioctl proxy-config endpoint deploy/istio-eastwestgateway.istio-system
istioctl proxy-config endpoint deploy/istio-eastwestgateway.istio-system | grep forum

 

forum-vm 의 envoy config 확인 - Docs

# [forum-vm] istioctl 설치
export ISTIOV=1.17.8
echo 'export ISTIOV=1.17.8' >> /root/.bashrc

curl -s -L https://istio.io/downloadIstio | ISTIO_VERSION=$ISTIOV sh -
cp istio-$ISTIOV/bin/istioctl /usr/local/bin/istioctl

#
curl -s localhost:15000/config_dump | istioctl proxy-config listener --file -
curl -s localhost:15000/config_dump | istioctl proxy-config route --file -
curl -s localhost:15000/config_dump | istioctl proxy-config clusters --file -
curl -s localhost:15000/config_dump | istioctl proxy-config endpoint --file -
curl -s localhost:15000/config_dump | istioctl proxy-config secret --file -
RESOURCE NAME     TYPE           STATUS     VALID CERT     SERIAL NUMBER                               NOT AFTER                NOT BEFORE
default           Cert Chain     ACTIVE     true           310309461583688467984066399721764000962     2025-05-26T01:09:42Z     2025-05-25T01:07:42Z
ROOTCA            CA             ACTIVE     true           46141372426695670978289547947687101983      2035-05-23T01:04:09Z     2025-05-25T01:04:09Z

• 서비스가 만들어지면 WorkloadEntry 엔드포인트가 선택되고, 이를 사용해 istiod가 데이터 플레인을 설정한다.
• forum 서비스 요청 시도를 해보자

#
istioctl proxy-config cluster deploy/webapp.istioinaction --fqdn forum.forum-services.svc.cluster.local
istioctl proxy-config endpoint deploy/webapp.istioinaction | grep forum

# 로그 모니터링
kubectl logs -n istioinaction deploy/webapp -c istio-proxy -f
[2025-05-25T04:53:18.841Z] "GET /api/users HTTP/1.1" 503 UH no_healthy_upstream - "-" 0 19 0 - "" "beegoServer" "63377970-9d0f-4591-a4d4-039b4321863d" "forum.forum-services:80" "-" outbound|80||forum.forum-services.svc.cluster.local - 10.10.200.72:80 :0 - default
[2025-05-25T04:53:18.839Z] "GET /api/users HTTP/1.1" 500 - via_upstream - "-" 0 27 2 2 "" "curl/8.7.1" "63377970-9d0f-4591-a4d4-039b4321863d" "webapp.istioinaction.io" "172.16.0.8:8080" inbound|8080|| 127.0.0.6:36439 172.16.0.8:8080 :0 outbound_.80_._.webapp.istioinaction.svc.cluster.local default

# 자신의 PC
curl -s -H "Host: webapp.istioinaction.io" http://$APP_IP:30000/api/catalog/
while true; do curl -s -H "Host: webapp.istioinaction.io" http://$APP_IP:30000/api/catalog/ ; echo; date; sleep 1; done

curl -s -H "Host: webapp.istioinaction.io" http://$APP_IP:30000/api/users
curl -s -H "Host: webapp.istioinaction.io" http://$APP_IP:30000/api/users -I
HTTP/1.1 500 Internal Server Error

• UH 응답 플래그는 ‘정상 업스트림 없음’으로, 클러스터에 트래픽을 라우팅할 수 있는 정상 엔드포인트가 없을 경우에만 나타난다.
• webapp 에는 forum 서비스의 엔드포인프가 없다는 뜻이다.

 

forum 워크로드 상태 확인하기 VERIFYING THE HEALTH OF THE FORUM WORKLOAD

WorkloadEntry 의 상태, 좀 더 정확히는 트래픽을 수신할 준비 상태 readiness 를 확인해보자

#
kc get workloadentries -n forum-services -o yaml
...
  status:
    conditions:
    - lastProbeTime: "2025-05-25T04:34:59.371581082Z"
      lastTransitionTime: "2025-05-25T04:34:59.371581355Z"
      message: 'Get "http://192.168.10.200:8080/api/healthz": dial tcp 127.0.0.6:0->192.168.10.200:8080:
        connect: connection refused' 
      status: "False" # 헬스체크가 실패하여, 워크로드가 비정상 상태임
      type: Healthy
...

# testpc : 아직 8080 서비스가 실행되지 않았다!
ss -tnlp | grep 8080

가상머신에서 forum 애플리케이션 시작하기 STARTING THE FORUM APPLICATION IN THE VM

forum 바이너리를 다운로드하고, 권한을 주고, 8080 포트에서 트래픽을 수신하도록 실행하자.

# forum-vm
wget -O forum https://git.io/J3QrT
file forum
chmod +x forum
./forum

# forum-vm
curl http://localhost:8080/api/healthz -v

ss -tnlp | grep 8080
LISTEN 0      4096               *:8080             *:*    users:(("forum",pid=15081,fd=3))

# k8s-s
istioctl proxy-config cluster deploy/webapp.istioinaction --fqdn forum.forum-services.svc.cluster.local
istioctl proxy-config endpoint deploy/webapp.istioinaction --cluster 'outbound|80||forum.forum-services.svc.cluster.local' -o json
istioctl proxy-config endpoint deploy/webapp.istioinaction --cluster 'outbound|80||forum.forum-services.svc.cluster.local'
ENDPOINT                STATUS      OUTLIER CHECK     CLUSTER
192.168.10.200:8080     HEALTHY     OK                outbound|80||forum.forum-services.svc.cluster.local

#
kc get workloadentries -n forum-services -o yaml
...
  status:
    conditions:
    - lastProbeTime: "2025-05-25T05:02:23.116408430Z"
      lastTransitionTime: "2025-05-25T05:02:23.116409282Z"
      status: "True"
      type: Healthy
...

 

다시 요청해보자!

# 자신의 PC
curl -s -H "Host: webapp.istioinaction.io" http://$APP_IP:30000/api/users
while true; do curl -s -H "Host: webapp.istioinaction.io" http://$APP_IP:30000/api/users ; echo; date; sleep 1; done

# 로그 모니터링
kubectl logs -n istioinaction deploy/webapp -c istio-proxy -f
[2025-05-25T05:05:51.328Z] "GET /api/users HTTP/1.1" 200 - via_upstream - "-" 0 5645 28 27 "218.153.65.54" "beegoServer" "888f982d-f7f3-4232-ac0b-826cf65ef294" "forum.forum-services:80" "192.168.10.200:8080" outbound|80||forum.forum-services.svc.cluster.local 172.16.0.8:38170 10.10.200.72:80 218.153.65.54:0 - default
[2025-05-25T05:05:51.326Z] "GET /api/users HTTP/1.1" 200 - via_upstream - "-" 0 3679 30 30 "218.153.65.54" "curl/8.7.1" "888f982d-f7f3-4232-ac0b-826cf65ef294" "webapp.istioinaction.io" "172.16.0.8:8080" inbound|8080|| 127.0.0.6:36439 172.16.0.8:8080 218.153.65.54:0 outbound_.80_._.webapp.istioinaction.svc.cluster.local default

 

• 이렇게 클러스터 서비스에서 WorkloadEntry 로의 트래픽 흐름을 검증했다.
• 또한 이스티오가 어떻게 트래픽을 받을 준비가 되지 않은 워크로드로 트래픽을 보내지 않는지도 보여줬다.
• 단순히 데이터 플레인에 그 엔드포인트를 설정하지 않는 것이다.
• 이 예제에서는 그 이점이 잘 드러나지 않았을 수도 있지만, 운영 환경 클러스터에서는 이런 방식이 클라이언트가 오류를 반환하는 인스턴스로 트래픽을 보내는 것을 방지하고 그 대신에 정상 인스턴스만 라우팅하게 된다.

 

13.3.6 컨트롤 플레인이 가상머신 설정: 상호 인증 강제 VMs are configured by the control plane: Enforcing mutual authentication

• 가상머신이 메시에 통합돼 사이드카 프록시가 네트워크 트래픽을 관리하므로, 이스티오의 풍부한 기능을 가상머신에 적용할 수 있다.
• 이를 시연하기 위해, 트래픽 상호 인증을 강제하는 PeerAuthentication 을 만들어 보안을 강화해보자
• 지금은 가상머신의 8080 포트를 노출해뒀기 때문에 연결할 수 있은 사람은 누구나 요청을 처리할 수 있다. 누구나, 심지어 권한이 없는 사용자도!
• 메시에 통합되지 않은 로컬 컴퓨터에서 가상머신으로 요청을 보내 이를 확인해볼 수 있다.

# 자신의 PC에서 요청
curl -is $FORUM:8080/api/users | grep HTTP
HTTP/1.1 200 OK

• 요청이 처리됐다. 예상한 바이지만, 앞으로는 금지할 것이다.
• 그러기 위해 메시에 상호 인증 트래픽만 처리하는 메시 범위 정책을 설정할 것이고, 그 결과로 서비스를 무단 접근으로부터 보호할 것이다.

#
cat istio-in-action/book-source-code-master/ch13/strict-peer-auth.yaml
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

kubectl apply -f istio-in-action/book-source-code-master/ch13/strict-peer-auth.yaml
kubectl get peerauthentication -A

정책이 데이터 플레인에 배포될 때까지 잠시 기다리자. 그런 다음, 상호 인증되지 않은 트래픽이 금지됐는지 확인한다.

# 자신의 PC에서 요청
curl -is $FORUM:8080/api/users -v

# istio-ingressgateway 경유 요청 
while true; do curl -s -H "Host: webapp.istioinaction.io" http://$APP_IP:30000/api/users ; echo; date; sleep 1; done

 

• 출력을 보면 webapp의 요청이 처리됐는데, 이는 가상머신이 컨트롤 플레인이 적용한 설정을 준수함을 보여준다.
• PeerAuthentication 정책은 하나의 예시일 뿐이다. 비슷하게 모든 이스티오 API를 사용해 가상머신의 프록시를 설정할 수 있다.

 

13.4 DNS 프록시 이해하기 Demystifying the DNS proxy

DNS 프록시는 이스티오 사이드카의 새 구성 요소로, 이 절의 목표는 DNS 프록시가 클러스터 내 서비스의 호스트네임을 해석하는 방법을 이해시키는 것이다.

13.4.1 DNS 프록시가 클러스터 호스트네임을 해석하는 방법 How the DNS proxy resolves cluster hostnames (실습~)

• 클러스터 내 호스트네임을 해석하는 데 관련된 단계를 모두 이해하기 위해 webapp.istioinaction 호스트네임이 해석되는 구체적인 과정을 따라가볼 것이다.
• 단계를 그림 13.14에 표시돼 있다.

1. 클라이언트는 webapp.istioinaction 을 해석하기 위해 DNS 쿼리를 만든다
2. 운영체제가 DNS 해석을 처리한다. 운영체제는 먼저 hosts 파일에 정의된 항목 중에 호스트네임과 일치하는 것이 있는지 확인한다.
   • 일치하는 항목이 없으면 요청을 기본 DNS 해석기 resolver 로 전달한다.
3. 우분투의 기본 DNS 해석기는 systemd-resolverd(로컬 애플리케이션에 호스트네임 해석을 제공하는 시스템 서비스)이며, 루프백 주소 127.0.0.53에서 53 포트를 리스닝한다.
   • 그러나 요청은 절대로 거기에 도달하지 않는데, 요청을 DNS 프록시로 리다이렉트하도록 istio-agent 가 Iptables 규칙을 설정하기 때문이다.
4. DNS 프록시에는 서비스 메시 내에서 알려진 서비스를 해석하기 위한 항목들이 포함돼 있다.
   • 호스트네임이 일치하면 해석되며, webapp.istioinaction이 그런 경우다.
   • 컨트롤 플레인이 NDS로 설정하기 때문이다.
5. 그렇지 않고 클러스터 서비스가 아니면 DNS 프록시가 물러나 resolv.conf 파일에 명시된 네임서버로 넘기며, 호스트네임은 여기서 해석되거나 해석하는 데 실패한다.

• 각 단계를 검증해보자.
• systemd-resolverd(127.0.0.53 에서 수신 중인)로 향하는 DNS 쿼리를 Iptables 규칙이 로컬호스트의 포트 15053에서 UDP 및 TCP 패킷을 수신 중인 DNS 프록시로 리다이렉트하는 것부터 확인해보자.

# [forum-vm]
# Iptables 규칙 확인 : proxyConfig.proxyMetadata ISTIO_META_DNS_CAPTURE="true" 설정 시 아래 규칙 추가됨
iptables-save | grep 'to-ports 15053'
-A OUTPUT -d 127.0.0.53/32 -p udp -m udp --dport 53 -j REDIRECT --to-ports 15053
-A ISTIO_OUTPUT -d 127.0.0.53/32 -p tcp -m tcp --dport 53 -j REDIRECT --to-ports 15053

DNS 쿼리 트래픽이 DNS 프록시 포트로 리다이렉트되는 것을 볼 수 있다. 포트 정보 확인하자.

# tcp, udp 를 127.0.0.1 에 port 15053 에서 이스티오 에이전트(pilot-agent)가 DNS 프록시 처리 확인
netstat -ltunp | egrep 'PID|15053'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:15053         0.0.0.0:*               LISTEN      3195/pilot-agent
udp        0      0 127.0.0.1:15053         0.0.0.0:*                           3195/pilot-agent

# 해당 주소로 DNS 쿼리해보자
dig +short @localhost -p 15053 webapp.istioinaction
10.10.200.48

dig +short @localhost -p 15053 catalog.istioinaction
dig +short @localhost -p 15053 forum.forum-services


# (옵션)
dig +short @localhost -p 15053 www.daum.net
daum-4vdtymgd.kgslb.com.
121.53.105.193


# (옵션) coredns 쿼리 로그 확인
KUBE_EDITOR="nano" kubectl edit cm -n kube-system coredns
apiVersion: v1
data:
  Corefile: |
    .:53 {
        log
        errors
        health
...

# 설정 반영되는데 다소 시간 소요
kubectl logs -n kube-system -l k8s-app=kube-dns -f

 

• 예상대로 15053 포트에서 수신 중인 pilot-agent 가 FQDN 을 해석한다. 우리 예제는 요청을 해석하기 위해 DNS 서버를 직접 지정했는데, 그럴 필요가 없다.
• 애플리케이션이 호스트네임을 해석할 때는 Iptable 규칙에 따라 요청이 자동으로 이 포트로 리다이렉트된다.
• 다음으로는 컨트롤 플레인이 DNS 프록시에 어떤 항목을 설정했는지 알아보자.

 

13.4.2 DNS 프록시가 인식하는 호스트네임은 무엇인가? Which hostnames is the DNS proxy aware of?

• DNS 프록시가 인식하는 항목을 모두 찾으려면 istiod의 디버그 엔드포인트를 사용해야 한다.
• 디버그 엔드포인트를 사용하면 모든 워크로드의 사이드카에 대한 NDS 설정을 쿼리할 수 있다.
• 우리가 관심 있는 워크로드 이름인 forum-vm 부터 선택해보자.

#
istioctl proxy-status | awk '{print $1}'
catalog-77fdb4997c-f8qj4.istioinaction
istio-eastwestgateway-86f6cb4699-4xfsn.istio-system
istio-ingressgateway-7b7ccd6454-pv8zp.istio-system
forum-vm.forum-services
webapp-684c568c59-vrj97.istioinaction

# NDS 설정을 가져올 때 proxyID 파라미터에 이름을 사용한다.
kubectl -n istio-system exec deploy/istiod -- curl -Ls "localhost:8080/debug/ndsz?proxyID=forum-vm.forum-services" | jq
{
  "resource": {
    "@type": "type.googleapis.com/istio.networking.nds.v1.NameTable",
    "table": {
      "catalog.istioinaction.svc.cluster.local": {
        "ips": [
          "10.10.200.138"
        ],
        "registry": "Kubernetes",
        "shortname": "catalog",
        "namespace": "istioinaction"
      },
      "forum.forum-services.svc.cluster.local": {
        "ips": [
          "10.10.200.72"
        ],
        "registry": "Kubernetes",
        "shortname": "forum",
        "namespace": "forum-services"
      },
      "webapp.istioinaction.svc.cluster.local": {
        "ips": [
          "10.10.200.48"
        ],
        "registry": "Kubernetes",
        "shortname": "webapp",
        "namespace": "istioinaction"
      },
...

 

• 요약된 출력은 webapp 서비스를 보여주는데, webapp.istioinaction.svc.cluster.local ****라는 이름에 매핑된 IP 주소 목록을 포함하고 있다.
• 출력을 살펴보면 webapp.istioinaction 같은 짧은 변형 variation 이 없다는 것을 확인할 수 있다. 그럼 어떻게 해석이 작동했는가?
• 아주 간단한다. istio-agent 가 NDS 설정을 받을 때, 다음과 같이 쿠버네티스 클러스터에서 설정될 모든 변형을 만들어낸다.
  • webapp.istioinaction
  • webapp.istioinaction.svc
  • webapp.istioinaction.svc.cluster
• 그리고 모두 동일한 IP 목록 주소, 즉, 앞 선 목록에서 봤던 10.10.200.48로 해석된다 → 아래 도메인들은 ndot 5 설정으로 변형 작성으로 보임

#
istioctl proxy-config route deploy/webapp.istioinaction --name 80 -o json
...
                "name": "webapp.istioinaction.svc.cluster.local:80",
                "domains": [
                    "webapp.istioinaction.svc.cluster.local",
                    "webapp",
                    "webapp.istioinaction.svc",
                    "webapp.istioinaction",
                    "10.10.200.48"
...

• 핵심은 다음과 같다.
  • DNS 프록시는 istiod가 알고 있는 서비스들로 설정된다.
  • istio-agent는 호스트네임의 더 짧은 변형들을 생성한다 (쿠버네티스 내의 경험과 일치시키기 위함이다)
  • 이런 DNS 프록시 내의 레코드는 클러스터 내 서비스 호스트네임을 해석하는 데 사용된다.
  • 클러스터가 아닌 호스트네임(퍼블릭 도메인 같은)쿼리는 머신에서 처음 설정한 네임서버로 넘어간다.

13.5 에이전트 동작 커스터마이징하기 Customizing the agent’s behavior

• 에이전트는 로그 내용, 로그 형식, 에이전트가 인증서를 발급받기 위해 요청할 인증서 수명 설정 같은 동작 등 다양한 설정 선택지가 있다.
• 예를 들어 두 가지 수정을 하길 원한다고 해보자.
  • DNS 프록시의 로깅 수준을 debug로 올린다.
  • 인증서 수명을 12시간으로 줄인다.
• 사이드카용 설정 파일인 /var/lib/istio/envoy/sidecar.env 를 업데이트하면 된다.

#
cat /var/lib/istio/envoy/sidecar.env
grep "^[^#]" /var/lib/istio/envoy/sidecar.env # 주석 처리

#
echo 'ISTIO_AGENT_FLAGS="--log_output_level=dns:debug"' >> /var/lib/istio/envoy/sidecar.env
echo 'SECRET_TTL="12h0m0s"' >> /var/lib/istio/envoy/sidecar.env
grep "^[^#]" /var/lib/istio/envoy/sidecar.env # 주석 처리
ISTIO_AGENT_FLAGS="--log_output_level=dns:debug"
SECRET_TTL="12h0m0s"

# 변경 사항 적용
systemctl restart istio


# www.daum.net 도메인은 질의 처리를 하지 못해서, 로컬에 resolver DNS 서버를 통해 질의 로그 확인.
tail -f /var/log/istio/istio.log
2025-05-25T07:23:03.660035Z	debug	dns	response for hostname "www.daum.net." not found in dns proxy, querying upstream
2025-05-25T07:23:03.662845Z	debug	dns	upstream response for hostname "www.daum.net." : ;; opcode: QUERY, status: NOERROR, id: 30399
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: ; udp: 65494

;; QUESTION SECTION:
;www.daum.net.	IN	 A

;; ANSWER SECTION:
www.daum.net.	77	IN	CNAME	daum-4vdtymgd.kgslb.com.
daum-4vdtymgd.kgslb.com.	5	IN	A	121.53.105.193

#
dig +short @localhost -p 15053 www.daum.net

 

• DNS 프록시에 대한 디버그 로그를 볼 수 있다.
• 인증서가 로테이션되면 /etc/certs/cert-chain.pem 파일에 저장된 새 인증서의 만료 시간을 검사할 수도 있다.
• 모든 설정 옵션 목록은 이스티오의 pilot-agent 문서를 참조하자 - Docs

 

13.6 메시에서 WorkloadEntry 제거하기 Removing a WorkloadEntry from the mesh & 13장 내용 정리

• 가상머신이 메시에 자동 등록되던 것처럼, 삭제되면 정리된다. 시도해보자.
  • AWS 가상머신용 EC2 를 삭제하자 → 시간이 조금 지난 후, WorkloadEntry 가 정리됐는지 확인하자.

#
watch kubectl get workloadentries -A
kubectl get workloadentries -A
No resources found

클라우드 네이티브 워크로드의 일시성을 지원하려면 워크로드 항목을 자동으로 정리(삭제)하는 것이 자동 등록만큼 중요하다.

 

쿠버네티스 파드와 가상머신을 메시에 통합하는 방법 간의 차이를 나열.

기능	쿠버네티스 구현	가상머신 구현
프록시 설치	istioctl로 직접 주입하거나 웹훅으로 자동 주입	직접 다운로드해 설치
프록시 설정	사이드카 주입 중 완료	istioctl을 사용해 WorkloadGroup에서 설정을 생성하고 프록시가 있는 가상머신으로 전송
워크로드 ID 부트스트랩	서비스 어카운트 토큰이 쿠버네티스 메커니즘에 의해 주입	서비스 어카운트 토큰을 가상머신으로 수작업으로 전송
헬스 체크	쿠버네티스가 Readiness / Liveness 프로브 수행	WorkloadGroup에 Rediness 프로브 설정
등록	쿠버네티스가 처리	WorkloadGroup의 구성원으로 가상머신 자동 등록
DNS 해석	클러스터 내 FQDN을 해석하는 데 DNS 서버 사용, DNS 프록시를 사용할지는 선택 가능	istiod가 DNS 프록시를 설정해 FQDN을 해석

• 여기서 한 가지 유의 사항을 강조하고 싶다.
• 간단히 말하면, 우리는 프록시를 수작업으로 설치하고 구성했으며, 이 방식은 워크로드를 메시에 통합하는 방법을 구석구석 모두 보여주는 데 도움이 됐다.
• 그러나 실제 프로젝트에서는 이 과정을 자동화해야 한다. 가상머신을 메시에 수작업으로 추가하면 메시가 아주 취약해진다.
• 따라서 그럴 경우, 서비스를 복구하기 위해 새벽 3시에 가상머신을 수작업으로 재구성하고 메시에 등록할 것을 요구받는 불상사가 일어날 수 있다.
• 자동화라는 단어가 벅차게 들릴 수 있다.
• 그러나 실제로 오늘날의 프로젝트들은 좋은 관행들을 따라 가상머신을 구축 및 배포하는 자동화를 갖추고 있어 보통 패커 packer.io , 앤서블 ansible.com , 테라폼 terraform.io 같은 도구를 사용한다.
• 그러나 기존 자동화가 있으면 일거리가 줄어드므로, 애플리케이션에 이스티오의 사이드카를 설치하고 설정과 토큰을 제공하도록 스크립트를 업데이트하기만 하면 된다.
• 그러면 마침내 가상머신이 메시에 통합된다.

실습 후 자원 삭제 : AWS CloudFormation Stack 삭제

 

요약

• 가상머신은 이스티오 v1.9에서 베타로 승격됐다. 앞으로는 더 많은 개선이 기대되며, 향후 몇 달 동안 흥미로운 개발 영역이 될 것이다.
  • 동시에 이미 성숙한 상태이므로, 여기서 다룬 내용은 바뀌지 않을 것으로 예상한다.
• WorkloadGroup 및 WorkloadEntry 를 사용하면 가상머신을 메시에 자동 등록할 수 있다.
• 자동 등록은 가상머신에서 워크로드의 고가용성을 달성하는 데 중요한다. Auto-registration is important to achieve high availability of workloads in VMs.
• istioctl은 가상머신을 istiod에 연결하는 데 필요한 가상머신 설정을 생성할 수 있다. istioctl can generate VM configuration for it to connect to istiod.
• east-west 게이트웨이는 가상머신이 연결할 수 있도록 istiod를 노출한다. East-west gateways expose istiod so that VMs can connect to it.
• DNS 프록시는 클러스터 내부의 호스트네임을 해석하면 istiod가 NDS API로 설정한다.
• 가상머신 사이드카는 다른 워크로드와 마찬가지로 이스티오 설정을 준수한다.