Skip to content

Azure Container Orchestratoin #3

Jump to bottom
manchiro edited this page Jul 15, 2020 · 5 revisions

day1 day2 day3

Workflowy : https://workflowy.com/s/msa/27a0ioMCzlpV04Ib#/69f581576ade

1. Ingress

  • 리소스를 많이 사용하므로 k8s의 노드수를 2--> 4개로 늘림.
  • Service 는 L4 레이어로 TCP 레벨에서 Pod 를 로드밸런싱 함.
  • Istio는 지능적인 서비스 임. 카나리 배포를 진행할 수 있음.

1.1 Ingress 설치

  • Helm 설치
    • 명령으로 설치 여부 확인 : helm은 k8s에서 설치할 수 있는 패치지명
    • helm : kubectl 로 kubectl이 바라보는 클러스터로 명령어를 요청하게 됨.
  • ingress 설치 후 설치내용 확인
  • (Ingress Controller의 EXTERNAL-IP가 API Gateway 엔드포인트: 메모 必)
skccadmin@SKCC18D00132:~/container-orchestration/yaml/liveness$ kubectl get all --namespace=ingress-basic
NAME                                                 READY   STATUS    RESTARTS   AGE
pod/nginx-ingress-controller-7747776989-c2sbf        0/1     Running   0          28s
pod/nginx-ingress-default-backend-5b967cf596-zfhj9   1/1     Running   0          28s

NAME                                    TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                      AGE
service/nginx-ingress-controller        LoadBalancer   10.0.71.163    20.39.191.211   80:30284/TCP,443:32425/TCP   28s
service/nginx-ingress-default-backend   ClusterIP      10.0.124.246   <none>          80/TCP                       28s

NAME                                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-ingress-controller        0/1     1            0           28s
deployment.apps/nginx-ingress-default-backend   1/1     1            1           28s

NAME                                                       DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-ingress-controller-7747776989        1         1         0       28s
replicaset.apps/nginx-ingress-default-backend-5b967cf596   1         1         1       28s
  • ingress는 NodePort type으로 expose 됨.

1.2 서비스 만들기

  • 로컬의 hosts 파일에 아래 내용을 추가함. (P.182~187)

    20.39.191.211 blue.example.com green.example.com

  • ping blue.example.com 또는 green.example.com 으로 확인
  • namespace 기본 설정 하기

    kubectl config set-context --current --namespace=ingress-basic

  • Lab. Ingress
  • Springcloud의 G/W 를 주로 사용함.

2. Job

  • 한번 수행하고 끝나는 작업
  • CronJob: Job 컨트롤러에 의해 실행되는 작업을 주기적으로 스케줄링 해 주는 컨트롤러

3. Resource Assign & Management

  • 쿠버네티스에서 Pod 를 어느 노드에 배포할지 결정하는 것을 스케줄링이라 함
  • PoD의 Status Type
    • ImagePullBackOff : 이미지 명이 kubectl create deploy --image=... 부분이나 Deployment.yaml 등에 (--image:.... 부분) 잘못 기입된 경우
    • CrashLoopBackOff : 서비스가 올라오지 않은 경우
    • Pending Pod : 주로, worker node 갯수가 부족한 경우(95% 정도)
    • Evicted Pod : 이미 스케쥴링 되었던 pod 가 들어간 노드에 메모리나 CPU 가 부족해지면 기존에 잘 돌던 pod 가 쫓겨나는 경우가 생김. ScaleUp을 해주어야 함. 사양을 늘려주기
  • Resource Monitoring
$ kubectl get nodes
$ kubectl describe nodes
$ kubectl top nodes
$ kubectl top pods
  • Tracing / Monitoring / Logging

4. Resource Quota

  • 네임스페이스별로 사용 가능한 리소스 양을 정의

5. DaemonSets

  • Pod 를 각각의 노드에서 하나씩만 돌게 하는 형태로 Pod 를 관리하는 컨트롤러

6. StatefulSets (P.197)

  • 기본적인 MSA 는 Statefuless 로 처리함.
  • 이전의 컨트롤러 (Replica Set, Job) 등은 상태가 유지되지 않는 application 을 관리하는 용도지만 , StatefulSet 은 단어의 의미 그대로 상태를 가지고 있는 포드들을 관리하는 컨트롤러
  • 스테이트풀셋을 사용하면 볼륨을 사용해서 특정 데이터를 기록해두고 그걸 포드가 재시작했을 때도 유지할 수 있음

7. Real MSA Application Deployment

  • 실습해보자.

8. Kubernetes Architecture

  • Master node 구성정보
    • API 서버(신문가판대) : 요청된 모든 정보를 데이터 베이스에 저장함. Restful 방식.
    • Scheduler : Scheduling을 처리함. : 할당관리
    • Controller manager : 상태관리
    • Etcd. : Database Server : 키밸류 저장소
  • Worker node
    • 마스터 서버와 통신하면서 필요한 Pod 를 생성하고 네트워크와 볼륨을 설정
    • Container runtime
    • Kubulet : cri-shim(현재는 cri-o) Interface로 Pod와 통신함. Kubelet 은 Container Runtime Interface(CRI) 를 이용하여 컨테이너 런타임에연결
    • Kube-proxy

9. Istio(참고)

  • IBM/GCP는 managed 서비스로 되어 있음.

9.1 Service Mesh-Service to Service Communicator

  • Service Mesh 는 마이크로서비스 간의 통신을 담당하는 요소
  • 서비스간 통신을 위해서는 Service Discovery, Fault Tolerance, Traffice Routing, Security 등의 기능 필요.
  • 동기식 : url connection 으로 처리 . RestTemplate 로 처리.
  • Outer Architecture
  • Inner Architecture

9.2 Service Mesh (P.144)

  • 종류 : 코드 기반, 라이브러리 기반, Proxy 기반
  • Sidecar proxy = envoy = Inter micro service
  • API Gateway는 마이크로서비스 그룹의 외부 경계에 위치하여 역할을 수행하지만, Service Mesh는 경계 내부에서 그 역할을 수행
  • kiali : 모니터링 서비스

9.3 설치 & tutorial

skccadmin@SKCC18D00132:~/git/istio-tutorial$ cat customer/kubernetes/Gateway.yml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: customer-gateway
spec:
  selector:
    istio: ingressgateway # use istio default controller *** istio를 사용하겠다
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: customer-gateway
spec:
  hosts:
  - "*"
  gateways:
  - customer-gateway
  http:
  - match:
    - uri:
        prefix: /customer   # / customer로 접속이 되면 customer 로 routing 하겠다.
    rewrite:
      uri: /
    route:
    - destination:
        host: customer
        port:
          number: 8080
  • 서비스 메시 모니터링 및 트레이싱 시스템의 외부접속 환경설정
    • kubectl edit : 수행중인 서비스 정보를 변경할때
    • kubectl edit svc jaeger-query -n istio-system : 분산추적시스템
    • kubectl edit svc kiali -n istio-system : 모니터링
* service/istio-ingressgateway 40.82.130.173 
* jaeger : http://40.82.134.81:16686
* kiali : http://40.82.129.216:20001

9.4 Istio Improved Routing & Rule

  • (사용자 선호도에 따른 추천 서비스 라우팅 정책 설정)
  • (VirtualService, DestinationRule 설정, v2로 100% 라우팅)
  • VirutalService : 들어온 트래픽에 대한 라우팅 정책 관리
  • DestinationRule : 라우팅 대상 서비스로의 도달 규칙설정
  • Client 브라우저 유형별 스마트 라우팅
skccadmin@SKCC18D00132:~/git/istio-tutorial$ cat istiofiles/virtual-service-firefox-recommendation-v2.yml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation
spec:
  hosts:
  - recommendation
  http:
  - match:
    - headers:
        baggage-user-agent:
          regex: .*Firefox.*
    route:
    - destination:
        host: recommendation
        subset: version-v2
  - route:
    - destination:
        host: recommendation
        subset: version-v1

10. Circuit Breaking

  • Event Storming은 Message Queueing 방식으로 처리함.
  • 동기기반의 호출을 할때 시간지체가 발생할때 보완해 주는 것.
  • callback 을 가진 hystrix 임.
  • [CB 유스케이스]
      1. Connection Max & Pending 수에 따른 Circuit Breaker
# DestinationRule 를 생성하여 CB가 발생할 수 있도록 Connection pool 설정 
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: dr-httpbin
  namespace: istio-cb-ns

spec:
  host: httpbin
  trafficPolicy:   # istio의 두꺼비집 정책. circuit  오픈되면 흐르지 않음.
    connectionPool:
      http:
        http1MaxPendingRequests: 1   # 강제로 걸리도록 하기 위한것
        maxRequestsPerConnection: 1
EOF
    1. Load balancing pool의 인스턴스 상태에 기반한 Circuit Breaker. ==> 가장 많이 사용하는 타입
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: hello-server-1
  namespace: istio-cb-ns
  labels:
    app: hello
spec:
  containers:
  - name: hello-server-1
    image: docker.io/honester/hello-server:latest
    imagePullPolicy: IfNotPresent
    env:
    - name: VERSION
      value: "v1"
    - name: LOG
      value: "1"
---
apiVersion: v1
kind: Pod
metadata:
  name: hello-server-2
  namespace: istio-cb-ns
  labels:
    app: hello
spec:
  containers:
  - name: hello-server-2
    image: docker.io/honester/hello-server:latest
    imagePullPolicy: IfNotPresent
    env:
    - name: VERSION
      value: "v2"
    - name: LOG
      value: "1"
    - name: RANDOM_ERROR   # 20%의 확률로 오류 발생 
      value: "0.2"
---
apiVersion: v1
kind: Service
metadata:
  name: svc-hello
  namespace: istio-cb-ns
  labels:
    app: hello
spec:
  selector:
    app: hello
  ports:
  - name: http
    protocol: TCP
    port: 8080
EOF
  • 로그 정보 확인

    kubectl logs -f hello-server-2 -c hello-server-2 -n istio-cb-ns

  • status가 200 이 아니면 Retry 하게 됨.

    10번 호출 모두 성공한 보여지므로 클라이언트 요청에 따라 에러가 Return 되지는 않는다. 하지만, 실제로는 hello-server-2 pod 에서 내부 로직에 따라 20% 확률로 에러를 발생했고, 이에 클라이언트(httpbin Pod)의 Proxy가 자동으로 재 요청했음을 알 수 있다. 실 서비스 환경에서는 한번 503 Code가 발생하면, 지속해서 발생할 확률이 높으므로, Circuit Breaker를 통해 이를 차단해야 한다.

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: dr-hello
  namespace: istio-cb-ns
spec:
  host: svc-hello
  trafficPolicy:
    outlierDetection:   # 감지한다.
      interval: 1s
      consecutiveErrors: 1  # 지속적으로 1번이라도 발생하면
      baseEjectionTime: 3m   # 3분동안 라이팅 테이블에서 제외시킴
      maxEjectionPercent: 100   # 모든것이 방출됨. 단한번의 오류에 대해서 처리 하지 않음.
EOF
  • istio 설정정보 확인

    kubectl describe svc istio-ingressgateway -n istio-system

참고

  • 무료구독을 만들고 서비스 테스트 하면 제약이 많음. (public ip, 6core 초과 못함. ... 등)
  • 그래서 TCL 활용해 보시라~

"머리는 차갑게, 가슴은 따뜻하게" | [Top]

Azure Container Orchestratoin

Angular

Spring F/W #Day1

블록체인이해하기

Clone this wiki locally