티스토리 뷰
13장에서 다루는 내용
- 레거시 워크로드를 이스티오 서비스 메시에 통합하기
- 가상머신에 istio-agent 설치 및 설정하기
- 가상머신에 ID 프로비저닝하기
- 클러스터 서비스와 가상머신 서비스를 서로 노출하기
- 로컬 DNS 프록시를 사용해 클러스터 서비스의 FQDN 해석하기
https://istio.io/v1.17/blog/2021/simple-vms/
- 지금까지는 이스티오 서비스 메시를 컨테이너 및 쿠버네티스 관점에서 다뤘다.
- 그러나 실제 워크로드는 자주 가상머신이나 물리 머신에서 실행된다.
- 컨테이너와 쿠버네티스는 종종 기술 스택을 현대화하려는 노력의 일환으로 사용하며, 이번 장은 이 두 세계를 애플리케이션 네트워크 계층에서 이스티오로 연결하는 방법을 보여준다.
- 왜 단순히 레거시 워크로드를 현대화해서 쿠버네티스 클러스터에서 실행하는 것이 아니라 가상머신을 메시로 통합하는 것인지 궁금할 수 있다.
- 우리도 가능하면 그 접근법을 추천하지만, 몇몇 경우에는 그런 접근법이 불가능하거나 최소한 비용을 고려했을 때 불가능에 가까울 수 있다.
- 엔터프라이즈는 규제 준수 때문에 워크로드를 쿠버네티스 클러스터를 설정하고 운영할 전문 지식이 부족한 온프레미스에서 실행해야 할 수 있다.
- 애플리케이션을 컨테이너화하는 것은 그리 간단하지 않다. 어떤 애플리케이션은 다시 설계해야 할 수 있다. 어떤 애플리케이션에는 업데이트해야 하지만 다른 의존성과 충돌하는 의존성이 있을 수 있다. 즉, 의존성 지옥이다.
- 어떤 것들은 실행 중인 가상머신에 고유한 의존성이 있다.
- 이번 장에서는 사이드카 프록시를 설치하고 설정함으로써 어떤 워크로드든 메시의 일부로 삼을 수 있는 방법을 보여준다.
- 이 접급법은 레거시 워크로드가 있으며, 이 레거시 워크로드를 복원력 있고 안전하고 고가용성적인 방식으로 메시로 통합하길 원하는 엔터프라이즈에게 흥미로운 기능을 제공한다.
♣ 실습 환경 구성
더보기
책 실습 구성 istio-eastwestgateway 사용 시, Service(LoadBalancer)가 External-IP가 외부 공인 IP 필요한 복잡환경으로, 동일 네트워크로 변경 구성
구성 : VPC 1개, EC2 인스턴스 1대 (Ubuntu 22.04 LTS, t3.xlarge - vCPU 4 , Mem 16) , forum-vm 1대는 t3.small
istio-8w.yaml
- 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 접속 할 것!EC2 생성 수량 부족 실패 시 : 사용자 계정의 해당 리전에 EC2 최대 갯수 제한 일 경우, Service Quotas (EC2) 증설 요청으로 해결
- Limit Type(EC2 Instances) ⇒ 서울 리전, All Standard (A, C, D, H, I, M, R, T, Z) Instances, New limit value(40 정도)
k3s-s , forum-vm 각각 접속 후 확인
[자신의 PC] 배포된 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
k3s-s 접속 후 확인 : ssh -i <> ubuntu@3.38.151.222
kc get node -owide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME k3s-s Ready control-plane,master 2m12s v1.28.15+k3s1 192.168.10.10 <none> Ubuntu 22.04.5 LTS 6.8.0-1029-aws containerd://1.7.22-k3s1.28 hostnamectl ... Hardware Vendor: Amazon EC2 Hardware Model: t3.xlarge # (옵션) krew 설치 wget -O /root/krew-linux_amd64.tar.gz https://github.com/kubernetes-sigs/krew/releases/download/v0.4.4/krew-linux_amd64.tar.gz tar zxvf /root/krew-linux_amd64.tar.gz /root/krew-linux_amd64 install krew export PATH="$PATH:/root/.krew/bin" echo 'export PATH="$PATH:/root/.krew/bin:/root/go/bin"' >> /etc/profile kubectl krew install get-all neat view-secret rolesum pexec # (옵션) termshark 설치 DEBIAN_FRONTEND=noninteractive apt install termshark -y # 대화형창에서 yes 입력 tshark -D termshark -v
forum-vm 접속 후 확인 : ssh -i <> ubuntu@54.180.243.135
ip -br -c addr ip -c a hostnamectl ... Hardware Vendor: Amazon EC2 Hardware Model: t3.small # (옵션) termshark 설치 DEBIAN_FRONTEND=noninteractive apt install termshark -y # 대화형창에서 yes 입력 tshark -D termshark -v
13.1 이스티오의 가상머신 지원
※ 들어가며 : Istio’s VM support
- 가상머신을 메시에 통합하는 것은 이스티오 초기부터 지원됐지만, 제어 평면 외부에서 많은 해결책과 자동화가 필요했습니다.
- 이스티오의 가상머신 지원은 1.9.0에서 핵심 기능 일부가 구현되고 API가 적절한 접근법으로 결정되면서 베타 beta 로 승격됐다.
- 이때의 핵심 기능들이란 다음과 같다.
- 가상머신에서의 사이드카 프록시 설치 및 설정. istioctl 로 간소화됐다.
- 가상머신의 고가용성. 이스티오의 두 가지 새 리소스인 WorkloadGroup, WorkloadEntry 를 도입하면서 달성됐다.
- 가상머신에서 메시 내 서비스의 DNS 해석. 이스티오의 사이드카와 함께 설정되는 로컬 DNS 프록시를 사용해서 가능해졌다.
- 이번 장에서는 다룰 정보가 많으므로 이런 새 기능들을 고수준에서 다루는 것부터 시작한다.
- 그런 다음, 가상머신을 메시에 통합해 구체적인 예제로 작동시킬 것이다.
13.1.1 가상머신에서의 사이드카 프록시 설치 및 설정 단순화하기
- 가상머신이 메시의 일부가 되려면 다음을 해야 한다.
- 네트워크 트래픽을 관리할 사이드카 프록시 설치
- 프록시가 istiod에 연결해 메시 설정을 받도록 설정
- istiod에 인증하는 데 사용할 ID 토큰을 가상머신에 제공
- 그림 13.1은 워크로드가 메시의 일부가 되는 데 필요한 전제 조건을 보여준다.
- 쿠버네티스에서 실행되는 워크로드에도 같은 작업이 필요하다.
- 웹훅 webhook 이나 istioctl 을 사용해 사이드카를 자동으로 설치하고 설정한다
- ID 토큰을 소유한다. 쿠버네티스가 파드에 자동으로 주입한다
- 이런 편의성은 쿠버네티스 외부의 워크로드로 확장되지 않는다.
- 그러므로 가상머신 소유자는 프록시를 설치하고 설정해야 하며, 워크로드 ID용 부트스트랩 토큰을 제공해야 한다. 그러나 나서야 워크로드가 메시의 일부가 될 수 있다.
- Single-network architecture
- multi-network 시나리오에서는 VM workload가 Kubernetes cluster와 다른 network에 존재하므로, Pod가 VM의 IP address에 직접 통신할 수 없습니다. 이 경우 Istio east-west gateway(또는 cross-network traffic을 위해 구성된 ingress/egress gateway)가 두 network를 연결하는 bridge 역할을 합니다.
- control-plane communication과 data-plane traffic을 포함한 모든 traffic은 두 network 간에 gateway를 통해 흐릅니다. VM은 Istiod에 secure하게 연결하고 application traffic을 위한 mTLS tunnel을 설정할 수 있도록 gateway의 address로 설정되어야 합니다.
☞ 가상머신의 프로비저닝 ID 자세히 살펴보기 A CLOSER LOOK AT PROVISIONING IDENTITY FOR VMS
- 이스티오는 가상머신에 ID를 제공하는 신뢰의 원천으로 쿠버네티스를 사용한다.
- 이는 쿠버네티스에서 토큰을 만들고 머신에 전달하면서 동작한다.
- 이 토큰은 머신에 설치된 istio-agent가 가져가 istiod에 인증하는 데 사용한다.
- 그림 13.2와 13.3은 클러스터 워크로드와 가상머신 워크로드에서 ID가 제공되는 방식의 차이를 보여준다.
- 쿠버네티스가 토큰을 자동으로 파드에 주입한다는 점만 빼면 접근법은 비슷하다.
- 반면 가상머신에서는 서비스 메시 운영자가 이 작업을 수행해야 하는데, 수작업으로 토큰을 안전하게 가상머신으로 전달해야 한다.
- istio-agent는 이 토큰을 사용해 istiod에 인증하고, 그 결과 istiod가 SVID 형태로 그 ID를 발급한다.
- 이 솔루션의 단점은 서비스 메시 운영자가 Kubernetes에서 토큰을 자동으로 생성하고 이를 VM으로 안전하게 전송해야 한다는 점입니다.
- 이것은 많은 노력이 필요하지 않을 수도 있지만, 대부분의 조직이 다중 클라우드 전략을 따르는 경우 빠르게 많은 노력을 더하게 됩니다.
(참고) 플랫폼이 할당한 ID Platform-assigned identity
- 이스티오 커뮤니티에서는 서로 다른 클라우드 프로바이더의 머신에 워크로드 ID를 자동으로 제공하는 해결책을 개발 중이다.
- 이 방법은 가상머신의 플랫폼이 부여한 ID를 신뢰의 근원으로 사용하며, istio-agent가 이를 갖고 istiod에 인증하는 데 사용한다.
- 당연히 이스티오는 토큰 검증을 설정하는 API를 클라우드 프로바이더에 노출할 것이다. 전체 과정은 아래 시각화 확인
이 방법은 아직 개발되지 않았지만 ID 공급자 설계 문서를 참조 워크로드를 인증하는 데 플랫폼이 부여한 ID를 사용하는 방법
- 다음 예제에서는 머신 ID를 프로비저닝하기 위한 신뢰의 원천으로 쿠버네티스를 사용한다.
- 간결하게 하기 위해 토큰은 수작업으로 가상머신에 전달할 것이다.
13.1.2 가상머신 고가용성
- 가상머신에서 고가용성을 달성하고자 이스티오는 쿠버네티스가 컨테이너화된 워크로드에서 취하는 접근법을 매우 흡사하게 모방한다.
- 기본적으로 쿠버네티스는 다음 리소스로 고가용성을 달성한다.
- 디플로이먼트 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는 수동으로 생성할 수 있다. 그러나 권장하는 방식은 새로 뜬 워크로드가 메시에 자동으로 참가하는 워크로드 자동 등록을 이용하는 것이다.
워크로드 자동 등록 이해하기
- 워크로드를 자동 등록하는 동안, 워크로드는 제공받은 설정을 사용해 컨트롤 플레인에 연결하고 ID 토큰으로 자신이 WorkloadGroup의 일원임을 인증한다.
- 이 작업이 성공하면 컨트롤 플레인은 메시에서 가상머신을 나타내는 WorkloadEntry를 생성한다 (그림 13.4 참조).
- 메시 내의 가상머신을 WorkloadEntry로 표현하는 것은 여러 이유로 중요하다.
- 특히 쿠버네티스 서비스나 이스티오 ServiceEntry 리소스가 레이블 셀렉터로 워크로드를 선택해 트래픽을 라우팅할 백엔드로 사용할 수 있다.
- 실제 주소가 아니라 쿠버네티스 서비스(즉, 클러스터 내의 FQDN)로 워크로드를 선택하면, 클라이언트 측에 대한 별다른 지식이나 영향 없이도 정상적이지 않은 워크로드를 폐기하거나 늘어난 수요에 맞추기 위해 새 워크로드를 쉽게 띄울 수 있다.
- 그림 13.5는 어떻게 서비스를 사용해 WorkloadEntry와 파드를 겨냥할 수 있는지 보여준다.
- 예를 들어, 가상머신에서 실행하는 레거시 워크로드를 쿠버네티스에서 실행하는 현대화 워크로드로 (마이그레이션) 이전할 때 위험을 줄이려는 경우가 여기에 해당할 수 있다.
- 워크로드를 병렬로 실행한 다음, 서비스 메시의 트래픽 전환 기능을 사용해(5장에서 설명) 모든 트래픽을 가상머신에서 파드로 점차 옮긴다.
- 이 과정에서 오류가 늘어나면 트래픽을 가상머신으로 되돌릴 수 있는 선택지도 갖고 있는 것이다.
이스티오가 수행하는 헬스 체크 이해하기
- 워크로드가 서비스 메시의 일부가 되고 나면, 트래픽을 받을 준비가 돼야 하며 헬스 체크로 검사받는다.
- 서비스의 고가용성을 유지하려면 두 가지 헬스 체크가 필요하다 (쿠버네티스가 헬스 체크하는 방식과 비슷하다).
- readiness 프로브는 워크로드가 시작된 후 트래픽을 수신할 준비가 됐는지 확인한다. Readiness probes check whether a workload is ready to receive traffic once it starts.
- liveness 프로브는 애플리케이션이 실행 중일 때 정상인지 확인한다. 정상이 아니면 재시작해야 한다.
- liveness 프로브는 서비스 메시의 관심사가 아니다!
- 워크로드가 살아 있는지 확인하는 것은 실행 중인 플랫폼의 기능이다.
- 예를 들어, 플랫폼인 쿠버네티스가 Deployment 설정에서 정의한 프로브로 liveness 를 검사한다.
- 마찬가지로 워크로드를 클라우드의 가상머신에서 실행할 때는 클라우드의 기능을 사용해 liveness 프로브를 구현하고, 프로브가 실패하면 새 인스턴스를 띄우는 등 복구하기 위한 수정 조치를 취해야 한다.
- 다음은 가장 인기 있는 세 클라우드 프로바이더의 liveness 검사 및 자동 복구에 대한 문서다.
이스티오가 가상머신에서 readiness 프로브를 구현하는 방법
- 애플리케이션이 트래픽을 받을 준비가 됐는지는 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.
- 컨트롤 플레인은 상태를 사용해 그 워크로드로 라우팅할지 여부를 결정한다.
- 예를 들어 애플리케이션이 정상이면 데이터 플레인에 애플리케이션을 호스팅하는 가상머신의 엔드포인트를 설정한다.
- 그리고 그 반대도 마찬가지도. 애플리케이션이 비정상일 때 데이터플레인에서 엔드포인트를 제거한다.
- 서비스 메시 운영자는 WorkloadGroup에 애플리케이션 readiness 검사를 설정하고, 클라우드 프로바이더가 권장하는 방법에 따라 인프라 계층에 liveness 검사를 만들어야 한다.
- liveness 와 readiness 프로브에는 다른 설정을 사용하는 것을 추천한다.
- istio-agent 가 수행하는 readiness 프로브는 공격적이어야 하며 트래픽이 오류를 반환하는 인스턴스로 라우팅되는 것을 방지해야 한다.
- 클라우드 프로바이더가 수행하는 liveness 프로브는 좀 더 보수적이어야 하며 가상머신이 복구할 시간을 줘야 한다.
- 인스턴스를 너무 경솔하게 죽이지 않도록 하자. 인스턴스를 죽이면 유예 기간 grace period 없이 진행 중인 요청을 종료해 최종 사용자에게 실패를 보여주기 때문이다.
- 경험상 좋은 방법은 liveness 프로브보다 readiness 프로브가 항상 먼저 실패하는 것이다.
13.1.3 메시 내 서비스의 DNS 해석
가상머신은 쿠버네티스 클러스터 외부에 있으므로 쿠버네티스 내부 DNS 서버에 접근할 수 없다.
그 결과 가상머신은 클러스터 서비스의 호스트네임을 해석할 수 없다
이를 해결하는 것이 가상머신을 서비스 메시에 통합하기 위한 마지막 단계다.
먼저 왜 DNS 해석이 필요한지 궁금할 수 있다.
애플리케이션과 함께 배포되는 서비스 프록시는 트래픽을 모든 워크로드로 라우팅하는 설정을 갖고 있지 않은가?
그렇다. 프록시는 트래픽을 어떻게 라우팅할지에 관한 설정을 갖고 있다.
그러나 문제는 트래픽을 애플리케이션에서 꺼나 프록시로 가져오는 데 있다.
이를 위한 전체 조건은 호스트네임이 해석되는 것이다.
그렇지 않으면, 트래픽은 절대 애플리케이션을 떠나지 않으므로 엔보이 프록시로 리다이렉트될 수 없다.
이 문제는 그림 13.7에 시각화돼 있다.
앞서, 클러스터 호스트네임은 보통 모든 쿠버네티스 서비스를 설정해둔 프라이빗 private DNS 서버를 사용해 해석했다.
가상머신은 DNS 쿼리를 보내는 네임서버로 이 프라이빗 DNS 서버를 사용하도록 설정돼 있다. (A 레코드 동적 추가/변경/삭제 구현 필요)
쿠버네티스 내 워크로드의 동적인 성질 때문에 프라이빗 DNS 서버를 설정하는 과정은, 이런 변경 사항을 수신하고 DNS 서버를 동기화 상태로 유지하는 쿠버네티스 컨트롤러를 사용해 자동화돼야 했다.
exteranl-dns가 정확히 그 작업을 수행하는 오픈소스 솔루션이다. https://github.com/kubernetes-sigs/external-dns
그러나 이는 차선책이지 서비스 메시 사용자가 원하는 통합 솔루션은 아니다.
이스티오 후속 버전(1.8 이상)은 istio-agent 사이드카에 로컬 DNS 프록시를 도입했는데, istiod가 이 프록시에 메시 내 서비스를 모두 설정해둔다 (그림 13.8 참조).
DNS 프록시는 엔보이 프록시와 함께 이스티오 사이드카로 동작하며 애플리케이션의 DNS 쿼리를 처리하는데, 이 DNS 쿼리는 이스티오에서 일반적으로 트래픽을 포착하는 방법인 Iptable 규칙을 사용해 DNS 프록시로 리다이렉트된다.
istio-cni 를 사용할 때는 이 과정이 살짝 다르다.
DNS 프록시를 지속적으로 업데이트하고자 이스티오는 NDS Name Discovery Serivce 라는 새 API를 도입했다.
NDS를 사용하면, 메시에 쿠버네티스 서비스나 이스티오 ServiceEntry가 추가될 때마다 컨트롤 플레인이 데이터 플레인에 새 DNS 항목을 동기화한다.
그러나 DNS 프록시는 가상머신에 국한되지 않는다. DNS 프록시를 사용하면 링크 처럼 여러 추가 기능을 사용 할 수 있다 - Blog
지금까지 고수준 개념과 그 개념의 목표를 살펴봤다. 다음으로는 가상머신을 서비스 메시에 통합하면서 실제로 실행해보자.
- Istio DNS Proxying은 DNS roundtrip을 제거함으로 응답 속도 개선을 이룰 뿐 아니라 CoreDNS에 대한 부하를 급격히 제거한다.
- Istio proxy는 미리 sync한 Kubernetes Service, Pod 및 Istio ServiceEntry 내 주소를 통해 투명하게(즉, app 변경 없이) DNS 서비스를 이룬다. 나머지 주소에 대해서는 관여하지 않아 일반적 DNS lookup 경로를 그대로 따른다.
- 이외에도 DNS server 변경 없이 DNS를 추가 가능하거나, 자동으로 virtual IP를 할당함으로 외부 TCP 서비스(e.g. AWS RDS)를 이슈 없이 식별 가능해진다.
- DNS server 변경 없이 DNS 추가: DNS server에 등록되지 않은 domain에 대해, DNS server 업데이트 없이도 DNS 서비스가 가능하다. 해당 domain name과 IP를 Istio ServiceEntry 에 등록하면 되는데, 앞서 논했듯 DNS proxy는 ServiceEntry 내의 Domain Name, IP도 함께 보유하기 때문이다.
- Automatic VIP allocation: 동일 port를 사용하는 다수의 외부 TCP endpoint(e.g. Amazon RDS)를 ServiceEntry 로 등록할 경우, 임의로 VIP(class E; non-routable)를 각 endpoint에 부여하여 0.0.0.0 이 아닌 해당 VPC를 기반으로 listener를 등록한다.
Istio and DNS - Costin Manolache, Google
더보기
Istio and DNS - Costin Manolache, Google
https://youtu.be/f6w6MoPz_u8
- Istio DNS stub Features:
- DNS-over-XDS : Istiod handles the Service, ServiceEntry names
- Fallback to the pod resolver (/etc/resolv.conf or /var/lib/istio/resolve.conf) for names that are unknown to Istiod
- no DNS-Sec validation, only ‘.cluster.local’ and names in ServiceEntry and handled.
- Use case: name visibility - Service, cluster2, VM
- A Service defined in one clustesr is only visible the DNS server of that cluster.
- VMs have a separate DNS resolver - don’t know about the private DNS used in cluster1
- Other clusters have their own DNS resolvers
- Option for name visibility
- When Istio DNS is enabled, we watch all clusters and return the merged .cluster.local and ServiceEntry result to Istio clients in all environments
- VMs and other clusters use ‘bob.test.svc.cluster.local’ even if ‘bob’ service is not in that cluster.
- TCP Egress..
- DNS and Load Balancing..
- Egress with Istio DNS..
- Ambient and DNS..
13.2 인프라 준비하기 Setting up the infrastructure
구성환경 : cool-store 애플리케이션 호스팅
- webapp 과 catalog 서비스는 쿠버네티스 클러스터에 배포한다.
- forum 서비스는 가상머신에 배포한다.
- 클러스터와 가상머신이 다른 네트워크에 있다는 것은 주목할 만하다
- 가상머신에서 클러스터 서비스로 향햐는 트래픽을 리버스 프록시할 east-west 게이트웨이가 필요하기 때문이다.
13.2.1 서비스 메시 준비하기(실습)
더보기
istio 1.17.8 설치
# (옵션) 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.202.64.8 # 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 가상머신까지 메시 확인
컨트롤 플레인 업데이트(실습)
- 가상머신 통합 기능은 베타 단계이며 기본적으로 활성화돼 있지 않다. 그러므로 IstioOperator 정의를 사용해 이스티오 설치를 업데이트해야 한다 - Docs
- 이 IstioOperator 정의는 워크로드 자동 등록, 헬스 체크, DNS 쿼리를 캡처해 DNS 프록시로 리다이렉트하는 기능을 활성화한다.
- 이 기능들은 가상머신을 메시로 통합하는 데 필요하다.
# 컨트롤 플레인 업데이트 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"}}'
13.3.1 istiod와 클러스터 서비스들은 가상머신에 노출하기
- 가상머신이 메시의 일부분이 되려면 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에 접근하는 데 필요한 포트를 노출할 수 있다.
- 그림 13.11은 가상머신이 istiod와 클러스터 서비스들에 연결할 수 있도록 노출된 포트를 보여준다.
- 먼저 가상머신에서 메시 내 서비스로 향하는 요청을 리버스 프록시해주는 다중 클러스터 상호 TLS 포트(15443)을 노출해보자
istiod와 클러스터 서비스들은 가상머신에 노출하는 포트들 # 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 으로 워크로드 그룹 나타내기
- 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
- 쿠버네티스 서비스들이 이 워크로드 그룹으로 등록된 워크로드 엔트리를 선택할 수 있게 해준다.
- network
- 컨트롤 플레인이 이 속성을 사용해 트래픽을 가상머신으로 라우팅하도록 서비스 프록시를 설정한다. Using this property, the control plane configures service proxies to route traffic to the VM
- 같은 네트워크에 있으면 IP 주소를 사용한다. 다른 네트워크라면 그 네트워크에 배포된 east-west 게이트웨이를 사용한다.
- serviceAccount
- 워크로드의 ID를 나타낸다. 워크로드가 이 그룹의 멤버로 등록하려면, 이 서비스 어카운트 ID용 클레임을 제시해야 한다.
네임스페이스와 서비스 어카운트를 만들고 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 서비스 어카운트의 유효한 토큰을 제시할 수 있는 워크로드를 자동으로 등록하도록 설정된다.
가상머신의 사이드카용 설정 생성하기
- 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가 노출된다.
- 루트 인증서. istiod가 제시한 인증서의 진위를 검증하는 데 사용한다.
- 인증서 검증은 서비스 프록시와 istiod 사이의 보안 커넥션을 시작하기 전에 수행해야 하는 선행 작업이다.
- 서비스 어카운트 토큰.
- 서비스 메시. 네트워크, 공통 속성에 대한 설정. WorkloadGroup에 정의된 대로다.
- 이 설정이 있으면 서비스 프록시는 컨트롤 플레인에 보안 커넥션을 시작하고, 자신의 SVID를 가져오고, xDS로 엔보이 설정을 수신해 메시의 구성원이 될 수 있다.
생성된 파일을 가상머신을 전송하기
- 설정 파일에는 민감 정보(구체적으로는 서비스 어카운트 토큰)가 포함돼 있으므로 가상머신으로 안전하게 전송해야 한다.
- 시연을 위해 공수가 제일 적은 방법을 사용해 파일을 SSH를 통해 복사할 것이다.
- 이 방법은 안전하지만, 운영 환경에서는 당연히 이 과정이 자동화돼 수작업이 필요 없어야 한다.
더보기
# 임시로, 자신의 로컬 PC에 위 파일들 복사 : 바로 vm_ip 에 복사해도 되지만, 현재 실습 환경 편리성으로 경유 복사.
APP_IP=43.202.64.8
mkdir my-workload-files
scp -i ~/.ssh/kp-gasida.pem ubuntu@$APP_IP:/tmp/my-workload-files/\* ./my-workload-files # macOS
scp -i ~/.ssh/kp-gasida.pem 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=54.180.240.239
scp -i ~/.ssh/kp-gasida.pem ./my-workload-files/cluster.env ubuntu@$FORUM:/tmp/
scp -i ~/.ssh/kp-gasida.pem ./my-workload-files/istio-token ubuntu@$FORUM:/tmp/
scp -i ~/.ssh/kp-gasida.pem ./my-workload-files/mesh.yaml ubuntu@$FORUM:/tmp/
scp -i ~/.ssh/kp-gasida.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 설치 및 설정하기
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 클러스터 서비스로 트래픽 라우팅하기
트래픽이 클러스터 서비스로 라우팅되는지 확인하기 위해 가상머신에서 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
가상머신에서 요청한 트래픽이 클러스터 서비스에 도달하는 과정
- 트래픽이 애플리케이션을 떠나려면 먼저 그 호스트네임을 해석해야 한다. 즉, DNS 쿼리가 DNS 프록시로 리다이렉트돼야 한다.
- 이름이 IP 주소로 해석되면 애플리케이션은 아웃바운드 요청을 시작할 수 있다. 이 요청은 Iptables 규칙이 엔보이 프록시로 리다이렉트한다.
- 엔보이 프록시는 트래픽을 east-west 게이트웨이로 라우팅한다.
- 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로 라우팅하기
- 앞 절에서는 머신에서 클러스터 내부/메시 내부 서비스로의 라우팅을 확인해봤다. 이제 그 반대로 라우팅하는 것을 확인해보자.
- 즉, 클러스터 안에서 가상머신 워크로드로 라우팅할 것이다.
- 가상머신에서 실행 중인 서비스로 도달하려면 어떻게 요청을 보내야 할까? 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 워크로드 상태 확인하기
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 컨트롤 플레인이 가상머신 설정: 상호 인증 강제
- 가상머신이 메시에 통합돼 사이드카 프록시가 네트워크 트래픽을 관리하므로, 이스티오의 풍부한 기능을 가상머신에 적용할 수 있다.
- 이를 시연하기 위해, 트래픽 상호 인증을 강제하는 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 프록시가 클러스터 호스트네임을 해석하는 방법
- 클러스터 내 호스트네임을 해석하는 데 관련된 단계를 모두 이해하기 위해 webapp.istioinaction 호스트네임이 해석되는 구체적인 과정을 따라가볼 것이다.
- 단계를 그림 13.14에 표시돼 있다.
- 클라이언트는 webapp.istioinaction 을 해석하기 위해 DNS 쿼리를 만든다
- 운영체제가 DNS 해석을 처리한다. 운영체제는 먼저 hosts 파일에 정의된 항목 중에 호스트네임과 일치하는 것이 있는지 확인한다.
- 일치하는 항목이 없으면 요청을 기본 DNS 해석기 resolver 로 전달한다.
- 우분투의 기본 DNS 해석기는 systemd-resolverd(로컬 애플리케이션에 호스트네임 해석을 제공하는 시스템 서비스)이며, 루프백 주소 127.0.0.53에서 53 포트를 리스닝한다.
- 그러나 요청은 절대로 거기에 도달하지 않는데, 요청을 DNS 프록시로 리다이렉트하도록 istio-agent 가 Iptables 규칙을 설정하기 때문이다.
- DNS 프록시에는 서비스 메시 내에서 알려진 서비스를 해석하기 위한 항목들이 포함돼 있다.
- 호스트네임이 일치하면 해석되며, webapp.istioinaction이 그런 경우다.
- 컨트롤 플레인이 NDS로 설정하기 때문이다.
- 그렇지 않고 클러스터 서비스가 아니면 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 프록시가 인식하는 호스트네임은 무엇인가
- 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로 해석된다
#
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 에이전트 동작 커스터마이징하기
- 에이전트는 로그 내용, 로그 형식, 에이전트가 인증서를 발급받기 위해 요청할 인증서 수명 설정 같은 동작 등 다양한 설정 선택지가 있다.
- 예를 들어 두 가지 수정을 하길 원한다고 해보자.
- 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 제거하기
- 가상머신이 메시에 자동 등록되던 것처럼, 삭제되면 정리된다. 시도해보자.
- 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 를 사용하면 가상머신을 메시에 자동 등록할 수 있다.
- 자동 등록은 가상머신에서 워크로드의 고가용성을 달성하는 데 중요한다.
- istioctl은 가상머신을 istiod에 연결하는 데 필요한 가상머신 설정을 생성할 수 있다.
- east-west 게이트웨이는 가상머신이 연결할 수 있도록 istiod를 노출한다
- DNS 프록시는 클러스터 내부의 호스트네임을 해석하면 istiod가 NDS API로 설정한다.
- 가상머신 사이드카는 다른 워크로드와 마찬가지로 이스티오 설정을 준수한다.
Istio Traffic Flow
요청에 대한 트래픽 흐름만 표기됨, 요청에 대한 응답(리턴) 트래픽 흐름은 설명되어 있지 않음
Type 1: Remote Pod(or 외부) ⇒ Local Pod(Application Container) , 외부에서 Application 컨테이너로 요청 인입 시
Remote Pod(or 외부) → RREROUTING → ISTIO_INBOUND → ISTIO_IN_REDIRECT → Envoy 컨테이너 15006 (Inbound) → OUTPUT → ISTIO_OUTPUT RULE 1 → POSTROUTING → Local Pod (Application 컨테이너)
Type 2: Local Pod(Application Container) → Remote Pod(or 외부) , Application 컨테이너에서 외부(다른 파드)로 요청 시작 시
Local Pod (Application 컨테이너) → OUTPUT → ISTIO_OUTPUT RULE 9 → ISTIO_REDIRECT → Envoy 15001 (Outbound) → OUTPUT → ISTIO_OUTPUT RULE 4 → POSTROUTING → Remote Pod(or 외부)
Type 3: Prometheus(서버) → Local Pod(Application Container) , Prometheus(서버)가 Application에 메트릭 수집 시
Prometheus(서버) → RREROUTING → ISTIO_INBOUND (traffic destined for ports 15002, 15090 will go to INPUT) → INPUT → OUTPUT → ISTIO_OUTPUT RULE 3 → POSTROUTING → Local Pod(Application Container)
⇒ 해당 트래픽 흐름에서는 Sidecar Proxy(Envoy)를 경유하지 않는다!
Type 4: Local Pod → Local Pod , 예시) Application 컨테이너에 2개 이상의 서비스가 존재하고 하나의 서비스가 다른 서비스로 요청 시
Local Pod → OUTPUT → ISTIO_OUTPUT RULE 9 → ISTIO_REDIRECT → Envoy 15001（Outbound）→ OUTPUT → ISTIO_OUTPUT RULE 2 → ISTIO_IN_REDIRECT → Envoy 15006（Inbound）→ OUTPUT → ISTIO_OUTPUT RULE 1 → POSTROUTING → Local Pod
Type 5: Inter-process TCP traffic within Envoy, Envoy 내부 프로세스(UID/GID 1337)가 lo NICs 나 localhost 도메인 통신 시
Envoy process (Localhost) → OUTPUT → ISTIO_OUTPUT RULE 8 → POSTROUTING → Envoy process (Localhost)
Type 6: Sidecar to Istiod traffic , pilot-agent 프로세스가 설정 동기화를 위해 istiod(컨트롤 플레인)에 요청 트래픽을 전달 시
pilot-agent process → OUTPUT -> Istio_OUTPUT RULE 9 → Envoy 15001 (Outbound Handler) → OUTPUT → ISTIO_OUTPUT RULE 4 → POSTROUTING → Istiod(컨트롤 플레인)
https://brunch.co.kr/@growthminder/84
istio proxy의 작동원리
istio sidecar proxy의 화려한 패킷 가로채기 | istio는 쿠버네티스 클러스터 내에서 네트워크 흐름을 통제하는 오픈소스이다. istio는 Envoy 프록시를 사이드카(sidecar) 형태로 배포하여 트래픽을 관리한
brunch.co.kr
kind : k8s(1.32.2) 배포
더보기
#
kind create cluster --name myk8s --image kindest/node:v1.32.2 --config - <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
extraPortMappings:
- containerPort: 30000 # Sample Application
hostPort: 30000
- containerPort: 30001 # Prometheus
hostPort: 30001
- containerPort: 30002 # Grafana
hostPort: 30002
- containerPort: 30003 # Kiali
hostPort: 30003
- containerPort: 30004 # Tracing
hostPort: 30004
- containerPort: 30005 # kube-ops-view
hostPort: 30005
networking:
podSubnet: 10.10.0.0/16
serviceSubnet: 10.200.1.0/24
EOF
# 설치 확인
docker ps
# 노드에 기본 툴 설치
docker exec -it myk8s-control-plane sh -c 'apt update && apt install tree psmisc lsof wget bridge-utils net-tools dnsutils tcpdump ngrep iputils-ping git vim -y'
docker exec -it myk8s-control-plane sh -c 'DEBIAN_FRONTEND=noninteractive apt install termshark -y'
docker exec -it myk8s-control-plane tshark -D
docker exec -it myk8s-control-plane termshark -v
# (옵션) 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=30005 --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 확인
open "http://127.0.0.1:30005/#scale=1.5"
open "http://127.0.0.1:30005/#scale=1.3"
kind docker network 에 테스트용 PC(실제로는 컨테이너)와 웹 서버(실제로는 컨테이너) 배포
더보기
# kind 설치 시 kind 이름의 도커 브리지가 생성된다 : 172.18.0.0/16 대역
docker network ls
docker inspect kind
# '테스트용 PC(mypc)' 컨테이너 기동 : kind 도커 브리지를 사용하고, 컨테이너 IP를 지정 혹은 지정 없이 배포
docker run -d --rm --name mypc --network kind --ip 172.18.0.100 nicolaka/netshoot sleep infinity # IP 지정 실행 시
혹은 IP 지정 실행 시 에러 발생 시 아래 처럼 IP 지정 없이 실행
docker run -d --rm --name mypc --network kind nicolaka/netshoot sleep infinity # IP 지정 없이 실행 시
docker ps
# '웹서버(myweb1, myweb2)' 컨테이너 기동 : kind 도커 브리지를 사용
# https://hub.docker.com/r/hashicorp/http-echo
docker run -d --rm --name myweb1 --network kind --ip 172.18.0.101 hashicorp/http-echo -listen=:80 -text="myweb1 server"
docker run -d --rm --name myweb2 --network kind --ip 172.18.0.102 hashicorp/http-echo -listen=:80 -text="myweb2 server"
혹은 IP 지정 실행 시 에러 발생 시 아래 처럼 IP 지정 없이 실행
docker run -d --rm --name myweb1 --network kind hashicorp/http-echo -listen=:80 -text="myweb1 server"
docker run -d --rm --name myweb2 --network kind hashicorp/http-echo -listen=:80 -text="myweb2 server"
docker ps
# kind network 중 컨테이너(노드) IP(대역) 확인
docker ps -q | xargs docker inspect --format '{{.Name}} {{.NetworkSettings.Networks.kind.IPAddress}}'
/myweb2 172.18.0.102
/myweb1 172.18.0.101
/mypc 172.18.0.100
/myk8s-control-plane 172.18.0.2
# 동일한 docker network(kind) 내부에서 컨테이너 이름 기반 도메인 통신 가능 확인!
docker exec -it mypc curl myweb1
docker exec -it mypc curl myweb2
docker exec -it mypc curl 172.18.0.101
docker exec -it mypc curl 172.18.0.102
MetalLB 배포
더보기
# MetalLB 배포
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.9/config/manifests/metallb-native.yaml
# 확인
kubectl get crd
kubectl get pod -n metallb-system
# IPAddressPool, L2Advertisement 설정
cat << EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: default
namespace: metallb-system
spec:
addresses:
- 172.18.255.201-172.18.255.220
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: default
namespace: metallb-system
spec:
ipAddressPools:
- default
EOF
# 확인
kubectl get IPAddressPool,L2Advertisement -A
istio 1.26.0 설치
더보기
# myk8s-control-plane 진입 후 설치 진행
docker exec -it myk8s-control-plane bash
-----------------------------------
# istioctl 설치
export ISTIOV=1.26.0
echo 'export ISTIOV=1.26.0' >> /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
client version: 1.26.0
# demo 프로파일 컨트롤 플레인 배포
istioctl install --set profile=demo --set meshConfig.enableTracing=true -y
# 보조 도구 설치
kubectl apply -f istio-$ISTIOV/samples/addons
kubectl apply -f istio-$ISTIOV/samples/addons # nodePort 충돌 시 한번 더 입력
# 빠져나오기
exit
-----------------------------------
# 설치 확인 : istiod, istio-ingressgateway, crd 등
kubectl get all,svc,ep,sa,cm,secret,pdb -n istio-system
kubectl get crd | grep istio.io | sort
kubectl describe cm -n istio-system istio
...
Data
====
mesh:
----
accessLogFile: /dev/stdout
defaultConfig:
discoveryAddress: istiod.istio-system.svc:15012
defaultProviders:
metrics:
- prometheus
enablePrometheusMerge: true
enableTracing: true
...
docker exec -it myk8s-control-plane istioctl proxy-status
NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION
istio-egressgateway-675cdb9f4b-gwwqv.istio-system Kubernetes SYNCED (103s) SYNCED (103s) SYNCED (103s) IGNORED IGNORED istiod-7f898458c5-76tlg 1.26.0
istio-ingressgateway-6cd9bc7f5b-qslxd.istio-system Kubernetes SYNCED (103s) SYNCED (103s) SYNCED (103s) IGNORED IGNORED istiod-7f898458c5-76tlg 1.26.0
# istio-ingressgateway 서비스 : NodePort 변경 및 nodeport 지정 변경 , externalTrafficPolicy 설정 (ClientIP 수집)
kubectl patch svc -n istio-system istio-ingressgateway -p '{"spec": {"type": "LoadBalancer", "ports": [{"port": 80, "targetPort": 8080, "nodePort": 30000}]}}'
kubectl patch svc -n istio-system istio-ingressgateway -p '{"spec":{"externalTrafficPolicy": "Local"}}'
kubectl 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 메트릭 확인
open http://127.0.0.1:30001
# Grafana 접속
open http://127.0.0.1:30002
# Kiali 접속 : NodePort
open http://127.0.0.1:30003
# tracing 접속 : 예거 트레이싱 대시보드
open http://127.0.0.1:30004
Nginx 디플로이먼트와 서비스 배포
더보기
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
name: sa-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: websrv-nginx
spec:
replicas: 1
selector:
matchLabels:
app: websrv-nginx
template:
metadata:
labels:
app: websrv-nginx
spec:
serviceAccountName: sa-nginx
terminationGracePeriodSeconds: 0
containers:
- name: websrv-nginx
image: nginx:alpine
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: websrv-nginx
spec:
ports:
- name: svc-webport
port: 80
targetPort: 80
selector:
app: websrv-nginx
type: ClusterIP
EOF
Istio Gateway/VirtualService 설정 - Host (websrv.cloudneta.local) 기반 트래픽 라우팅 설정, 평문 통신 설정
더보기
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
name: mygateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: mywebsrv
spec:
hosts:
- "websrv.cloudneta.local"
gateways:
- mygateway
http:
- route:
- destination:
host: websrv-nginx
port:
number: 80
EOF
Istio 를 통한 Nginx (반복) 접속 테스트
더보기
#
kubectl get gw,vs
kubectl get svc -n istio-system istio-ingressgateway
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-ingressgateway LoadBalancer 10.200.1.168 172.18.255.201 15021:30692/TCP,80:30000/TCP,443:32017/TCP,31400:30929/TCP,15443:30272/TCP 62m
ISTIOGWVIP=$(kubectl get svc -n istio-system istio-ingressgateway -o jsonpath="{.status.loadBalancer.ingress[0].ip}")
echo $ISTIOGWVIP
# 접속 확인
docker exec -it mypc curl $ISTIOGWVIP -I # 실패 이유는?
docker exec -it mypc curl -s -H "Host: websrv.cloudneta.local" $ISTIOGWVIP # 성공 이유는?
# 반복 접속
ISTIOGWVIP=$(kubectl get svc -n istio-system istio-ingressgateway -o jsonpath="{.status.loadBalancer.ingress[0].ip}")
while true; do docker exec -it mypc curl -s -H "Host: websrv.cloudneta.local" $ISTIOGWVIP | grep title ; echo; date "+%Y-%m-%d %H:%M:%S"; sleep 1; done
# 로그 확인
kubectl logs -n istio-system -l app=istio-ingressgateway -f
kubectl logs -l app=websrv-nginx -c istio-proxy -f
# XFF 정보를 통해 클라이언트 IP 확인 가능
kubectl logs -l app=websrv-nginx -c websrv-nginx -f
127.0.0.6 - - [29/May/2025:13:40:20 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/8.7.1" "172.18.0.100"
(옵션) 자신의 로컬 PC에서 요청
# Nodeport 30000 으로 접속
curl -s -H "Host: websrv.cloudneta.local" http://127.0.0.1:30000 | grep title
<title>Welcome to nginx!</title>
# 반복 접속
while true; do curl -s -H "Host: websrv.cloudneta.local" http://127.0.0.1:30000 | grep title ; echo; date "+%Y-%m-%d %H:%M:%S"; sleep 1; done
※ kind(controlplane 1대) + istio-ingressgateway(NodePort)로 실습 가이드 + Istio 통신 흐름
Istio 트래픽 흐름 상세 분석
1. Istio 트래픽 흐름 상세 분석 case1 : testpc → nginx 파드 요청 트래픽
가. testpc ↔ Tcp8080[IstioIngressGW] ↔ Tcp80[istio-proxy/nginx] 구간 확인
더보기
# istio-ingressgateway 파드의 IP 확인
kubectl get pod -n istio-system -l app=istio-ingressgateway -o jsonpath='{.items[*].status.podIP}'
10.10.0.9
IGWIP=<출력된 IP>
IGWIP=10.10.0.9
# istio-ingressgateway 파드가 연결된 veth 정보 확인
docker exec -it myk8s-control-plane ip -c route | grep $IGWIP
10.10.0.9 dev veth1b80f0bd scope host
IGWVETH=<출력된 veth>
IGWVETH=veth1b80f0bd
# testpc <<=>> Tcp8080[IstioIngressGW] -> Tcp80[nginx] : testpc 와 IstioIngress 파드간 트래픽 덤프
docker exec -it myk8s-control-plane tcpdump -i $IGWVETH -nnq tcp port 8080
docker exec -it myk8s-control-plane sh -c "ngrep -tW byline -d $IGWVETH '' 'tcp port 8080'"
# testpc <<=>> Tcp8080[IstioIngressGW] -<<=>> Tcp80[istio-proxy/nginx] : IstioIngress 와 nginx 파드간 트래픽 덤프
docker exec -it myk8s-control-plane tcpdump -i $IGWVETH -nnq tcp port 80
docker exec -it myk8s-control-plane sh -c "ngrep -tW byline -d $IGWVETH '' 'tcp port 80'"
..
T 2024/10/18 09:37:32.649437 10.10.0.9:46038 -> 10.10.0.26:80 [AP] #7
GET / HTTP/1.1.
host: www.gasida.dev:30000.
user-agent: curl/8.7.1.
accept: */*.
x-forwarded-for: 172.18.0.3. <<= IstioIngress 파드가 XFF에 클라이언트IP를 담아서 nginx 파드로 전달
x-forwarded-proto: http.
x-envoy-internal: true.
...나. nginx 파드 내에서 iptables 정보 확인
더보기
# myk8s-control-plane 진입 후 설치 진행
docker exec -it myk8s-control-plane bash
------------------------------------------------------------
# myk8s-control-plane 에 network 네임스페이스 확인
lsns -t net
# nginx-pod 파드의 nginx-container 컨테이너 ID 추출
crictl ps --name nginx-container
crictl ps --name nginx-container -q
CID1=$(crictl ps --name nginx-container -q)
echo $CID1
# nginx-pod 파드의 nginx-container 컨테이너의 PID 추출
crictl inspect $CID1| jq
crictl inspect $CID1| jq '.info.pid'
CID1PID=$(crictl inspect $CID1| jq '.info.pid')
echo $CID1PID
# nginx-pod 파드의 네트워크 네임스페이스로 진입
nsenter -t $CID1PID -n /bin/bash
--------------------------------------
# IP 정보 확인
ip -c -4 addr show dev lo
ip -c -4 addr show dev eth0
11: eth0@if36: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65535 qdisc noqueue state UP group default link-netnsid 0
inet 10.10.0.26/24 brd 10.10.0.255 scope global eth0
...
# ss (socket statistics)로 시스템 소켓 상태 확인 : 15006 은 envoy 프로세스가 Listen 하고 있다
ss -tpnl '( dport = :15006 or sport = :15006 )'
# 현재 연결된 tcp 소켓 정보 확인
ss -tpnt '( dport = :15006 or sport = :15006 or sport = :80 or dport = :80 )'
# conntrack 정보 확인 후 초기화
conntrack -L
# iptables NAT 정보 확인
iptables -t nat --zero
# 트래픽 인입 시 TCP 경우 모든 트래픽을 15006 으로 리다이렉트한다, 일부 포트는 제외(15008, 15090, 15020, 15021)
iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 9 packets, 540 bytes)
pkts bytes target prot opt in out source destination
9 540 ISTIO_INBOUND tcp -- any any anywhere anywhere
...
Chain ISTIO_INBOUND (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN tcp -- any any anywhere anywhere tcp dpt:15008
0 0 RETURN tcp -- any any anywhere anywhere tcp dpt:15090
9 540 RETURN tcp -- any any anywhere anywhere tcp dpt:15021
0 0 RETURN tcp -- any any anywhere anywhere tcp dpt:15020
0 0 ISTIO_IN_REDIRECT tcp -- any any anywhere anywhere
Chain ISTIO_IN_REDIRECT (3 references)
pkts bytes target prot opt in out source destination
0 0 REDIRECT tcp -- any any anywhere anywhere redir ports 15006
# watch 로 모니터링 : testpc 에서0 접속 후 pkts/bytes 증가 부분 확인
conntrack -F && iptables -t nat --zero
watch -d "iptables -v --numeric --table nat --list PREROUTING ; echo ; iptables -v --numeric --table nat --list ISTIO_INBOUND ; echo ; iptables -v --numeric --table nat --list ISTIO_IN_REDIRECT"
conntrack -L
ss -tpnt '( dport = :15006 or sport = :15006 or sport = :80 or dport = :80 )'
# nginx-pod 파드의 네트워크 네임스페이스로 진입되어 있는 터미널 상태를 유지 : 아래에서 계속 사용 됨
다. istioctl proxy-config 로 envoy 정보 확인
더보기
# proxy-config listener 정보 확인
docker exec -it myk8s-control-plane istioctl proxy-config listener nginx-pod
docker exec -it myk8s-control-plane istioctl proxy-config listener nginx-pod --address 0.0.0.0 --port 15006
ADDRESSES PORT MATCH DESTINATION
...
0.0.0.0 15006 Trans: raw_buffer; App: http/1.1,h2c; Addr: *:80 Cluster: inbound|80||
0.0.0.0 15006 Trans: raw_buffer; Addr: *:80 Cluster: inbound|80||
# proxy-config route 정보 확인
docker exec -it myk8s-control-plane istioctl proxy-config route nginx-pod
docker exec -it myk8s-control-plane istioctl proxy-config route nginx-pod --name 80
NAME VHOST NAME DOMAINS MATCH VIRTUAL SERVICE
80 svc-nginx.default.svc.cluster.local:80 svc-nginx, svc-nginx.default + 1 more... /*
...
docker exec -it myk8s-control-plane istioctl proxy-config route nginx-pod --name 80 -o json | jq
...
{
"name": "svc-nginx.default.svc.cluster.local:80",
"domains": [
"svc-nginx.default.svc.cluster.local",
"svc-nginx",
"svc-nginx.default.svc",
"svc-nginx.default",
"10.200.1.228"
],
"routes": [
{
"name": "default",
"match": {
"prefix": "/"
},
"route": {
"cluster": "outbound|80||svc-nginx.default.svc.cluster.local",
"timeout": "0s",
"retryPolicy": {
"retryOn": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
"numRetries": 2,
...
# proxy-config cluster 정보 확인
docker exec -it myk8s-control-plane istioctl proxy-config cluster nginx-pod
docker exec -it myk8s-control-plane istioctl proxy-config cluster nginx-pod --fqdn svc-nginx.default.svc.cluster.local
SERVICE FQDN PORT SUBSET DIRECTION TYPE DESTINATION RULE
svc-nginx.default.svc.cluster.local 80 - outbound EDS
docker exec -it myk8s-control-plane istioctl proxy-config cluster nginx-pod --fqdn svc-nginx.default.svc.cluster.local -o json | jq
# proxy-config endpoint 정보 확인
docker exec -it myk8s-control-plane istioctl proxy-config endpoint nginx-pod
docker exec -it myk8s-control-plane istioctl proxy-config endpoint nginx-pod --port 80
docker exec -it myk8s-control-plane istioctl proxy-config endpoint nginx-pod --cluster "outbound|80||svc-nginx.default.svc.cluster.local" -o json
[
{
"name": "outbound|80||svc-nginx.default.svc.cluster.local",
"addedViaApi": true,
"hostStatuses": [
{
"address": {
"socketAddress": {
"address": "10.10.0.26",
"portValue": 80
...
라. (참고) nginx-pod 파드에 envoy 컨테이너 admin 페이지 접속 , istio-proxy 컨테이너 로그 확인
더보기
# istio-proxy 파드에 envoy 컨테이너 admin 접속 포트 포워딩 설정
kubectl port-forward nginx-pod 15000:15000 &
# envoy 컨테이너 admin 페이지 접속
open http://localhost:15000# 로그 확인
kubectl logs nginx-pod -c istio-proxy -f
# nginx-pod에 istio-proxy 에 로그 레벨 변경 : http 만 debug/info 변경 >> testpc에서 curl 접속 후 로그 정보 확인
kubectl exec -it nginx-pod -c istio-proxy -- curl -X POST http://localhost:15000/logging?http=debug
# 로그 확인
kubectl logs nginx-pod -c istio-proxy -f
# nginx-pod에 istio-proxy 에 로그 레벨 원복
kubectl exec -it nginx-pod -c istio-proxy -- curl -X POST http://localhost:15000/logging?http=warning
마. istio-proxy 컨테이너의 envoy(프로세스)를 통과하여 빠져 나가는 트래픽 확인
- nginx-pod 파드의 네트워크 네임스페이스로 진입되어 있는 터미널 상태에서 아래 입력
더보기
# envoy가 가로챈 후 lo로 SNAT 후 빠져나갈 때 iptables OUTPUT -> ISTIO_OUTPUT -> POSTROUTIN 체인 지나감
iptables -t nat -L -n -v
Chain OUTPUT (policy ACCEPT 6 packets, 1519 bytes)
pkts bytes target prot opt in out source destination
6 1519 ISTIO_OUTPUT 6 -- * * 0.0.0.0/0 0.0.0.0/0
Chain ISTIO_OUTPUT (1 references)
pkts bytes target prot opt in out source destination
1 291 RETURN 0 -- * lo 127.0.0.6 0.0.0.0/0
0 0 ISTIO_IN_REDIRECT 6 -- * lo 0.0.0.0/0 !127.0.0.1 tcp dpt:!15008 owner UID match 1337
0 0 RETURN 0 -- * lo 0.0.0.0/0 0.0.0.0/0 ! owner UID match 1337
5 1228 RETURN 0 -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 1337
0 0 ISTIO_IN_REDIRECT 6 -- * lo 0.0.0.0/0 !127.0.0.1 tcp dpt:!15008 owner GID match 1337
0 0 RETURN 0 -- * lo 0.0.0.0/0 0.0.0.0/0 ! owner GID match 1337
0 0 RETURN 0 -- * * 0.0.0.0/0 0.0.0.0/0 owner GID match 1337
0 0 RETURN 0 -- * * 0.0.0.0/0 127.0.0.1
0 0 ISTIO_REDIRECT 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 6 packets, 1519 bytes)
pkts bytes target prot opt in out source destination
# watch 로 모니터링 : testpc 에서 접속 후 pkts/bytes 증가 부분 확인
conntrack -F && iptables -t nat --zero
watch -d "iptables -v --numeric --table nat --list OUTPUT ; echo ; iptables -v --numeric --table nat --list ISTIO_OUTPUT ; echo ; iptables -v --numeric --table nat --list POSTROUTING"
conntrack -L
# lsof 확인
lsof -i TCP:80,15006 -n
...
envoy 26955 1337 39u IPv4 1298844 0t0 TCP 127.0.0.6:58477->10.10.0.26:http (ESTABLISHED)
...
# lo 인터페이스 로 tcpdump 할 경우 출발지 IP가 127.0.0.6으로 SNAT 되어서 빠져나감을 확인
tcpdump -nnqi lo not net 127.0.0.1
15:00:02.955442 IP 127.0.0.6.35151 > 10.10.0.26.80: tcp 239
15:00:02.955569 IP 10.10.0.26.80 > 127.0.0.6.35151: tcp 238
...
# lo 인터페이스도 RX/TX가 증가함을 확인
watch -d ifconfig lo
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 127341 bytes 404699497 (385.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 127341 bytes 404699497 (385.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
# ngrep 로 http 헤더 정보 확인 : 해당 요청(패킷)이 nginx 컨테이너로 전달 됨
ngrep -tW byline -d lo -v 'host 127.0.0.1' # 127.0.0.1 IP는 제외
T 2024/10/18 15:07:42.035857 127.0.0.6:58477 -> 10.10.0.26:80 [AP] #16
GET / HTTP/1.1.
host: www.gasida.dev:30000.
user-agent: curl/8.7.1.
accept: */*.
x-forwarded-for: 172.18.0.3.
x-forwarded-proto: http.
x-request-id: 76357e24-71a3-487b-94e1-ddf79b3c717d.
x-envoy-attempt-count: 1.
x-envoy-internal: true.
# (참고) 기본적으로 127.0.0.0/8 대역 통신은 lo local 통신 라우팅 처리함
ip route show table local
local 10.10.0.26 dev eth0 proto kernel scope host src 10.10.0.26
broadcast 10.10.0.255 dev eth0 proto kernel scope link src 10.10.0.26
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
바. 최종적으로 nginx 컨테이너에 클라이언트의 요청 트래픽이 도착한다.
더보기
# nginx 웹 데몬에 도착하여 액세스 로그 기록되고, 이후 200ok 리턴되며, XFF 헤더에서 클라이언트의 IP를 확인
kubectl logs nginx-pod -c nginx-container -f
127.0.0.6 - - [18/Oct/2024:15:26:24 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/8.7.1" "172.18.0.3"
2. Istio 트래픽 흐름 상세 분석 case1 : testpc ← nginx 파드 (2번 요청에 대한) 응답 트래픽
- nginx (웹 서버)컨테이너에서 리턴 트래픽(응답, 200 OK)를 클라이언트에 전달합니다.
- IPTables CT(Connection Table)에 정보를 참고해서 역변환 등이 적용되어 전달됩니다.
- 위(요청)에서 알아본 3번 과정 직전과 위 8번 과정의 NAT 트래픽 정보
- nginx-pod 파드의 네트워크 네임스페이스로 진입되어 있는 터미널 상태에서 아래 입력
# conntrack 정보 확인
conntrack -L --dst-nat
tcp 6 431999 ESTABLISHED src=10.10.0.9 dst=10.10.0.26 sport=46038 dport=80 src=10.10.0.26 dst=10.10.0.9 sport=15006 dport=46038 [ASSURED] mark=0 use=1
3. Istio 트래픽 흐름 상세 분석 case2 : ‘nginx 파드 → 외부 인터넷’에서 다운로드 시
가. 'nginx 컨테이너' 에서 외부 웹서버 요청
더보기
# 아래 처럼 'nginx 컨테이너' 에서 외부 웹서버 요청
kubectl exec -it nginx-pod -c nginx-container -- curl -s http://wttr.in/seoul
kubectl exec -it nginx-pod -c nginx-container -- curl -s http://ipinfo.io/city
kubectl exec -it nginx-pod -c nginx-container -- curl -k https://www.google.com | grep -o "<title>.*</title>";echo
# 반복 요청 : https는 암호화되니, http 접속을 사용 할 것
while true; do kubectl exec -it nginx-pod -c nginx-container -- curl -s http://ipinfo.io/city ; date "+%Y-%m-%d %H:%M:%S" ; echo "--------------" ; sleep 5; done
while true; do kubectl exec -it nginx-pod -c nginx-container -- curl -k https://www.google.com | grep -o "<title>.*</title>"; date "+%Y-%m-%d %H:%M:%S" ; echo "--------------" ; sleep 3; done
nginx-pod 파드의 네트워크 네임스페이스로 진입되어 있는 터미널 상태에서 아래 입력
# conntrack 정보 확인
conntrack -L --dst-nat
tcp 6 99 TIME_WAIT src=10.10.0.26 dst=142.250.207.4 sport=37812 dport=443 src=127.0.0.1 dst=10.10.0.26 sport=15001 dport=37812 [ASSURED] mark=0 use=1
src=10.10.0.26 dst=142.250.207.4 sport=37812 dport=443 # 최초 요청 트래픽 정보
src=127.0.0.1 dst=10.10.0.26 sport=15001 dport=37812 # 리턴 트래픽에서 IP/Port 정보를 보면, 출발지 포트가 15001 으로, 'istio-proxy' 경유를 했음을 알 수 있다
나. nginx → iptables → envoy 구간
더보기
nginx-pod 파드의 네트워크 네임스페이스로 진입되어 있는 터미널 상태에서 아래 입력
# nginx 파드에서 외부로 TCP 트래픽 요청(인입) 시, ISTIO_OUTPUT 에서 맨 마지막 줄에 매칭되고 이후 ISTIO_REDIRECT 에서 redir ports 15001 되어 'Envoy'로 인입됩니다.
## ISTIO_OUTPUT 은 envoy 를 빠져나와서 다시 한번 더 Rule 매칭 확인을 한다. envoy IN/OUT 구분을 위해서, UID 1337 조건을 확인함.
iptables -t nat -L -n -v
Chain OUTPUT (policy ACCEPT 687 packets, 52287 bytes)
pkts bytes target prot opt in out source destination
261 16819 ISTIO_OUTPUT 6 -- * * 0.0.0.0/0 0.0.0.0/0
Chain ISTIO_OUTPUT (1 references)
pkts bytes target prot opt in out source destination
2 351 RETURN 0 -- * lo 127.0.0.6 0.0.0.0/0
0 0 ISTIO_IN_REDIRECT 6 -- * lo 0.0.0.0/0 !127.0.0.1 tcp dpt:!15008 owner UID match 1337
0 0 RETURN 0 -- * lo 0.0.0.0/0 0.0.0.0/0 ! owner UID match 1337
147 9748 RETURN 0 -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 1337
0 0 ISTIO_IN_REDIRECT 6 -- * lo 0.0.0.0/0 !127.0.0.1 tcp dpt:!15008 owner GID match 1337
0 0 RETURN 0 -- * lo 0.0.0.0/0 0.0.0.0/0 ! owner GID match 1337
0 0 RETURN 0 -- * * 0.0.0.0/0 0.0.0.0/0 owner GID match 1337
0 0 RETURN 0 -- * * 0.0.0.0/0 127.0.0.1
112 6720 ISTIO_REDIRECT 0 -- * * 0.0.0.0/0 0.0.0.0/0
Chain ISTIO_REDIRECT (1 references)
pkts bytes target prot opt in out source destination
112 6720 REDIRECT 6 -- * * 0.0.0.0/0 0.0.0.0/0 redir ports 15001
# watch 로 모니터링 : testpc 에서 접속 후 pkts/bytes 증가 부분 확인
## 'owner UID match 1337' pkts/bytes 증가는 envoy 를 빠져나오서 매칭되어 증가됨
conntrack -F && iptables -t nat --zero
watch -d "iptables -v --numeric --table nat --list OUTPUT ; echo ; iptables -v --numeric --table nat --list ISTIO_OUTPUT ; echo ; iptables -v --numeric --table nat --list ISTIO_REDIRECT"
conntrack -L
nginx-pod 파드의 네트워크 네임스페이스로 진입되어 있는 터미널 상태에서 아래 입력
# lo 인터페이스 로 tcpdump로 확인
## 외부(인터넷) 목적지 IP/Port 를 127.0.0.1:15001로 Redirect 된 것을 확인
## 그 아래는 리턴 트래픽을 lo 에서 nginx 로 전달
tcpdump -nnqi lo
01:53:33.969167 IP 10.10.0.26.60212 > 127.0.0.1.15001: tcp 0
01:53:34.004123 IP 172.217.175.36.443 > 10.10.0.26.60212: tcp 6426
# lo 인터페이스도 RX/TX가 증가함을 확인
watch -d ifconfig lo
# ngrep 로 http 헤더 정보 확인
ngrep -tW byline -d lo
T 2024/10/19 02:06:19.323748 10.10.0.26:49648 -> 127.0.0.1:15001 [AP] #53
GET /city HTTP/1.1.
Host: ipinfo.io.
User-Agent: curl/7.88.1.
Accept: */*.
다. istioctl proxy-config 로 envoy 정보 확인 : 생략..
마. Envoy는 대리인(Proxy) 역할로 목적지 IP/Port 정보를 nginx 가 원래 요청한 정보로 변경하여 외부 웹서버에 연결
더보기
nginx-pod 파드의 네트워크 네임스페이스로 진입되어 있는 터미널 상태에서 아래 입력
#
tcpdump -nnqi eth0 tcp port 80
02:22:09.470964 IP 10.10.0.26.46252 > 34.117.59.81.80: tcp 699
02:22:09.633974 IP 34.117.59.81.80 > 10.10.0.26.46252: tcp 378
...
#
lsof -i TCP:80,15001 -n
envoy 26955 1337 42u IPv4 2071968 0t0 TCP 10.10.0.26:45406->34.117.59.81:http (ESTABLISHED)
envoy 26955 1337 44u IPv4 2071145 0t0 TCP 10.10.0.26:46252->34.117.59.81:http (ESTABLISHED)
...
# ISTIO_OUTPUT 은 envoy 를 빠져나와서 다시 한번 더 Rule 매칭 확인을 한다. envoy IN/OUT 구분을 위해서, UID 1337 조건을 확인함.
## envoy 는 ㅕㅕ
## 즉 맨 하단에 ISTIO_REDIRECT 매칭되기 전에 그 위에 'owner UID match 1337' 매팅이 되어서 RETURN 을 통해 외부로 라우팅 된다.
## ISTIO_OUTPUT 을 envoy 로 보내고, 돌아오는 flow 를 구분하기 위해서 User ID(1337) 매칭을 확인 함.
iptables -t nat -L -n -v
Chain OUTPUT (policy ACCEPT 687 packets, 52287 bytes)
pkts bytes target prot opt in out source destination
261 16819 ISTIO_OUTPUT 6 -- * * 0.0.0.0/0 0.0.0.0/0
Chain ISTIO_OUTPUT (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN 0 -- * lo 127.0.0.6 0.0.0.0/0
0 0 ISTIO_IN_REDIRECT 6 -- * lo 0.0.0.0/0 !127.0.0.1 tcp dpt:!15008 owner UID match 1337
0 0 RETURN 0 -- * lo 0.0.0.0/0 0.0.0.0/0 ! owner UID match 1337
7 2730 RETURN 0 -- * * 0.0.0.0/0 0.0.0.0/0 owner UID match 1337
0 0 ISTIO_IN_REDIRECT 6 -- * lo 0.0.0.0/0 !127.0.0.1 tcp dpt:!15008 owner GID match 1337
0 0 RETURN 0 -- * lo 0.0.0.0/0 0.0.0.0/0 ! owner GID match 1337
0 0 RETURN 0 -- * * 0.0.0.0/0 0.0.0.0/0 owner GID match 1337
0 0 RETURN 0 -- * * 0.0.0.0/0 127.0.0.1
6 360 ISTIO_REDIRECT 0 -- * * 0.0.0.0/0 0.0.0.0/0
# watch 로 모니터링 : testpc 에서 접속 후 pkts/bytes 증가 부분 확인
## 'owner UID match 1337' pkts/bytes 증가는 envoy 를 빠져나오서 매칭되어 증가됨
conntrack -F && iptables -t nat --zero
watch -d "iptables -v --numeric --table nat --list OUTPUT ; echo ; iptables -v --numeric --table nat --list ISTIO_OUTPUT"
conntrack -L
istio-proxy 컨테이너(envoy 프로세스, pilot-agent 프로세스)의 user id 확인
#
kubectl exec -it nginx-pod -c istio-proxy -- ps -ef
UID PID PPID C STIME TTY TIME CMD
istio-p+ 1 0 0 Oct18 ? 00:00:23 /usr/local/bin/pilot-agent proxy sidecar --domain default.svc.cluster.local --proxyLogLevel=warnin
istio-p+ 16 1 0 Oct18 ? 00:03:53 /usr/local/bin/envoy -c etc/istio/proxy/envoy-rev.json --drain-time-s 45 --drain-strategy immediat
kubectl exec -it nginx-pod -c istio-proxy -- id
uid=1337(istio-proxy) gid=1337(istio-proxy) groups=1337(istio-proxy)
- istio 애플리케이션 요구 사항 중 일부 - Docs
- Application UIDs: Ensure your pods do not run applications as a user with the user ID (UID) value of 1337 because 1337 is reserved for the sidecar proxy.
라. 이후 노드를 통해서 외부에 요청이 전달됨
4. Istio 트래픽 흐름 상세 분석 case2 : ‘nginx 파드 ← 외부 인터넷’ 요청에 대한 응답 리턴 시
- 웹 서버에서 리턴 트래픽이 파드에 돌아오는 과정은 case1 에서 알아본 흐름과 유사합니다.
- 다만, 파드 내로 인입 시 목적지 포트가 다르므로 이므로, ‘Nginx 컨테이너’ 로 바로 가지 않고, 'Istio-proxy 컨테이너' 로 먼저 가게 됩니다.
실습 종료 후 리소스 삭제
더보기
# CloudFormation 스택 삭제
aws cloudformation delete-stack --stack-name mylab
# [모니터링] 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
'Istio' 카테고리의 다른 글
| [9주차] Ambient Mesh 실습 (1) | 2025.06.08 |
|---|---|
| [9주차] Ambient Mesh (3) | 2025.06.07 |
| [7주차] 14. 이스티오의 요청 처리 기능 확장하기 (0) | 2025.05.24 |
| [7주차] 12. 이스티오 스케일링 (0) | 2025.05.24 |
| [6주차] 11. 튜닝 (2) | 2025.05.16 |