네트워크 스터디 7주차-1

 
Istio 
 
Istio는 마이크로서비스 아키텍처에서 서비스 간 통신, 보안, 모니터링 등을 일관되게 관리하기 위해 등장한 서비스 메쉬(Service Mesh)
솔루션임. 마이크로서비스가 증가하면서 서비스 간의 복잡한 네트워크 관리, 보안 및 로깅 문제를 해결하기 위해 등장
 
 

 
 핑크색 부분이 데이터 플레인 역할을 함

 

 
 
 
Pilot:
서비스 메쉬 내의 트래픽 관리를 담당하는 컴포넌트. 각 마이크로서비스 사이에 설정된 트래픽 규칙을 Envoy 프록시에게 전달하고, 이들이 올바르게 동작할 수 있도록 제어. 이를 통해 서비스 간의 로드 밸런싱, 서비스 디스커버리 등을 중앙에서 관리함
Citadel:
보안을 담당하는 컴포넌트. 서비스 간의 통신을 TLS로 암호화하기 위한 인증서 발급 및 관리, 서비스 인증(Authentication) 등을 제공. 이를 통해 서비스 간의 통신을 안전하게 보장
Galley:
구성(config)을 관리하는 컴포넌트. Istio 내의 정책 및 설정 파일을 검증하고, 올바른 형식으로 변환하여 다른 Istio 컴포넌트들이 사용할 수 있도록 배포
 
LDS(Listener Discovery Service): Envoy가 트래픽을 수신할 포트를 정의
RDS(Route Discovery Service): 각 listenr에 대한 라우팅 규칙을 동적으로 제공
CDS(Cluster Discovery Service): Envoy에서 클러스터의 구성을 동적으로 제공
EDS(Endpoint Discovery Service): 클러스터에 속하는 엔드포인트를 동적으로 제공
 
 
 
 
 

 
 
 
envoy
https://www.envoyproxy.io/docs/envoy/latest/intro/what_is_envoy
Service discovery and dynamic configuration: Envoy optionally consumes a layered set of dynamic configuration APIs for centralized management. The layers provide an Envoy with dynamic updates about: hosts within a backend cluster, the backend clusters themselves, HTTP routing, listening sockets, and cryptographic material. For a simpler deployment, backend host discovery can be done through DNS resolution (or even skipped entirely), with the further layers replaced by static config files.
 
 
 

설정하고 테스트 해봄 로컬도됨

 
 
 
 

url rewrite

 
 

k3-s 에서도 테스트함
 

 

clusters
 

listener
 
========================================================================================2. Istio sidecar mode 설치, Gateway API 사용하지 않는 방식으로 진행
 

demo profile 로 진행

istio 설치

생성된 리소스 확인

생성된 crd

 

 

 

istio-ingressgateway 파드 안에 envoy가 있다.
 

pod를 describe 해보면 istio-proxy 컨테이너 하나 밖에 없다. svc 없다.

istio-ingressgateway 서비스 NodePort로 변경
 

control plane에 해당하는 istiod 배포 확인
 

tcp 소켓 정보 확인 (pilot)
 

envoy-proxy 에서 istod와 연결되어 있다라는 것을 의미
 
istio-proxy 내에 2개의 중요한 요소가 있음 - isito-proxy와 envoy

unix 도메인 소켓

 
 

자동으로 주입해줄수 있도록 설정

 
 

k3s-s)
# istio ingress gw NodePort(HTTP 접속용) 변수 지정 : 아래 ports[0] 은 어떤 용도의 포트일까요?
export IGWHTTP=$(kubectl get service -n istio-system istio-ingressgateway -o jsonpath='{.spec.ports[1].nodePort}')
echo $IGWHTTP
IGWHTTP=<각자 자신의 NodePort>

32363 노드포트

`

셋팅전에는 안됨
 

1번: k3-s
2번: testpc
3번: 로컬 맥
 

 
 
 
 

cat <<EOF | kubectl create -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kans-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-websrv
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deploy-websrv
  template:
    metadata:
      labels:
        app: deploy-websrv
    spec:
      serviceAccountName: kans-nginx
      terminationGracePeriodSeconds: 0
      containers:
      - name: deploy-websrv
        image: nginx:alpine
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: svc-clusterip
spec:
  ports:
    - name: svc-webport
      port: 80
      targetPort: 80
  selector:
    app: deploy-websrv
  type: ClusterIP
EOF

 
이걸 k3-s에 적용하면 로그로
 

CDS, EDS, LDS, RDS가 찍히는 것을 볼 수 있다.

auto injection 해준것의 결과 istio-proxy가 생김

Init Container가 네트워크 네임스페이스에 iptable 셋팅한다.
 

실습 흐름

cat <<EOF | kubectl create -f -
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: test-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: nginx-service
spec:
  hosts:
  - "$MYDOMAIN"
  gateways:
  - test-gateway
  http:
  - route:
    - destination:
        host: svc-clusterip
        port:
          number: 80
EOF

 

배포함

 

 

istioctl proxy-status

 

로컬에서 요청을 보내봄

 
client ip 로 127.0.0.6 으로 찍히는건 뒤에서 설명함
 

envoy에 설정된 전체 설정을 확인 가능함.

istioctl proxy-config all deploy-websrv-778ffd6947-rxwh4

파일럿 디스커버리 -> 파일럿 agent -> unix 소켓 통해서 -> envoy 까지 전달됨
(pilot : istio-proxy 내 uds 로 envoy 와 grpc 통신, istiod 받아온 dynamic config 를 envoy 에 전달)

istio-proxy 사용자 정보 확인

 

 

 

 
복제 pod

kubectl debug $(kubectl get pod -l app=deploy-websrv -oname) -it --image=nicolaka/netshoot -c netdebug --share-processes --copy-to=websrv-debug --profile='sysadmin'

 

 
 

 

Istio 컨테이너 접속

 
 

dynamic_resources, static_resources
 

 
 
========================================================================================
BookInfo 예제
 

 
배포 예제

# 모니터링
watch -d 'kubectl get pod -owide;echo;kubectl get svc'

# Bookinfo 애플리케이션 배포
echo $ISTIOV
cat ~/istio-$ISTIOV/samples/bookinfo/platform/kube/bookinfo.yaml
kubectl apply -f ~/istio-$ISTIOV/samples/bookinfo/platform/kube/bookinfo.yaml

# 확인
kubectl get all,sa

# product 웹 접속 확인
kubectl exec "$(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}')" -c ratings -- curl -sS productpage:9080/productpage | grep -o "<title>.*</title>"

# 로그
kubetail -l app=productpage -f

 

모니터링

접근 확인

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  # The selector matches the ingress gateway pod labels.
  # If you installed Istio using Helm following the standard documentation, this would be "istio=ingress"
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 8080
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
  - "*"
  gateways:
  - bookinfo-gateway
  http:
  - match:
    - uri:
        exact: /productpage
    - uri:
        prefix: /static
    - uri:
        exact: /login
    - uri:
        exact: /logout
    - uri:
        prefix: /api/v1/products
    route:
    - destination:
        host: productpage
        port:
          number: 9080

 

 
접속 확인

 #
export IGWHTTP=$(kubectl get service -n istio-system istio-ingressgateway -o jsonpath='{.spec.ports[1].nodePort}')
echo $IGWHTTP
32759

# 접속 확인
kubectl get svc -n istio-system istio-ingressgateway
curl -s http://localhost:$IGWHTTP/productpage
curl -s http://192.168.10.101:$IGWHTTP/productpage
curl -s http://192.168.10.102:$IGWHTTP/productpage

# 정보 확인
echo $MYDOMAIN
cat /etc/hosts

#
curl -s http://$MYDOMAIN:$IGWHTTP/productpage

노드로도 접근

 
# 

coredns 덕분에 가능

[productpage-v1-d5789fdfb-ghdtf] [2024-10-19T12:47:49.799Z] "GET /details/0 HTTP/1.1" 200 - via_upstream - "-" 0 178 2 1 "-" "curl/7.81.0" "7d6ea69d-bbcf-9642-b7a4-4ab3397889ce" "details:9080" "172.16.0.5:9080" outbound|9080||details.default.svc.cluster.local 172.16.0.7:58026 10.10.200.53:9080 172.16.0.7:51696 - default
[productpage-v1-d5789fdfb-ghdtf] [2024-10-19T12:47:49.808Z] "GET /reviews/0 HTTP/1.1" 200 - via_upstream - "-" 0 358 19 18 "-" "curl/7.81.0" "7d6ea69d-bbcf-9642-b7a4-4ab3397889ce" "reviews:9080" "172.16.2.7:9080" outbound|9080||reviews.default.svc.cluster.local 172.16.0.7:39408 10.10.200.62:9080 172.16.0.7:37084 - default
[productpage-v1-d5789fdfb-ghdtf] [2024-10-19T12:47:49.793Z] "GET /productpage HTTP/1.1" 200 - via_upstream - "-" 0 9429 40 39 "172.16.0.0" "curl/7.81.0" "7d6ea69d-bbcf-9642-b7a4-4ab3397889ce" "www.gasida.dev:32363" "172.16.0.7:9080" inbound|9080|| 127.0.0.6:59961 172.16.0.7:9080 172.16.0.0:0 invalid:outbound_.9080_._.productpage.default.svc.cluster.local default

 

내가 만든 클러스터의 특정 노드IP/내가확인한노드포트/proudct/page/ 
이렇게 요청을 계속 보내면 3번의 경우의수에 맞게 나눠서 나옴-> 위의 구조 참고