Traefik - kubernetes 첫 시험

traefik 은 전단 부하 이퀄 라이저 로 마이크로 서비스 구조, 특히 kubernetes 등 편성 도구 에 좋 은 지원 을 합 니 다.nginx 등에 비해 traefik 은 백 엔 드 용기 의 변 화 를 자동 으로 감지 하여 자동 서비스 발견 을 실현 할 수 있 습 니 다.오늘 시험 해 보 았 는데, 여기에 사용 과정 을 기록 하 겠 습 니 다.
1. Kubernetes 서비스 노출 안내
kubernetes 1.2 버 전부터 kubernetes 는 Ingress 대상 을 제공 하여 대외 노출 서 비 스 를 실현 했다.지금까지 kubernetes 는 모두 세 가지 노출 서비스 방식 이 있 습 니 다.

LoadBlancer Service

NodePort Service

Ingress

1.1、LoadBlancer Service
LoadBlancer Service 는 kubernetes 깊이 가 클 라 우 드 플랫폼 과 결 합 된 구성 요소 입 니 다.LoadBlancer Service 노출 서 비 스 를 사용 할 때 실제 적 으로 바닥 클 라 우 드 플랫폼 에 부하 이퀄 라이저 를 만들어 외부 노출 서 비 스 를 신청 합 니 다.현재 LoadBlancer Service 가 지원 하 는 클 라 우 드 플랫폼 은 상대 적 으로 완선 되 었 다. 예 를 들 어 외국 의 GCE, Digital Ocean, 국내의 아 리 클 라 우 드, 개인 클 라 우 드 OpenStack 등 이다. LoadBlancer Service 깊이 가 클 라 우 드 플랫폼 과 결합 되 었 기 때문에 일부 클 라 우 드 플랫폼 에서 만 사용 할 수 있다.
1.2、NodePort Service
NodePort Service 는 말 그대로 클 러 스 터 의 모든 node 에 하나의 포트 를 노출 한 다음 에 이 포트 를 특정한 service 에 투사 하여 이 루어 진 것 입 니 다. node 의 포트 마다 많 지만 안전성 과 용이 성 (서비스 가 많 으 면 어 지 럽 고 포트 충돌 문제) 으로 인해 실제 사용 이 많 지 않 을 수 있 습 니 다.
1.3、Ingress
Ingress 라 는 것 은 1.2 후에 야 나타 난 것 입 니 다. Ingress 사용 자 를 통 해 nginx 등 오픈 소스 의 역방향 대리 부하 이퀄 라이저 를 사용 하여 대외 노출 서 비 스 를 실현 할 수 있 습 니 다. 다음은 Ingress 를 상세 하 게 말씀 드 리 겠 습 니 다. traefik 은 Ingress 를 사용 하기 때 문 입 니 다.
Ingress 를 사용 할 때 보통 세 개의 구성 요소 가 있 습 니 다.
역방향 에이전트 부하 이퀄 라이저

Ingress Controller

Ingress

1.3.1 역방향 에이전트 부하 이퀄 라이저
역방향 프 록 시 부하 균형 기 는 매우 간단 하 다. 말하자면 nginx, apache 따위 이다.클 러 스 터 에서 역방향 프 록 시 부하 이퀄 라이저 는 자 유 롭 게 배치 할 수 있 고 Replication Controller, Deployment, DaemonSet 등 을 사용 할 수 있 지만 개인 적 으로 DaemonSet 방식 으로 배치 하 는 것 을 좋아 하기 때문에 편리 합 니 다.
1.3.2、Ingress Controller
Ingress Controller 는 실질 적 으로 모니터 로 이해 할 수 있 습 니 다. Ingress Controller 는 kubernetes API 와 끊임없이 접촉 하고 실시 간 으로 백 엔 드 서비스, pod 등 변 화 를 감지 합 니 다. 예 를 들 어 pod, service 증가 와 감소 등 입 니 다.이러한 변화 정 보 를 얻 은 후에 Ingress Controller 는 다음 의 Ingress 생 성 설정 과 결합 한 다음 에 역방향 프 록 시 부하 이퀄 라이저 를 업데이트 하고 그 설정 을 갱신 하여 서비스 발견 의 역할 을 합 니 다.
1.3.3、Ingress
Ingress 의 간단 한 이 해 는 규칙 의 정의 이다.예 를 들 어 특정한 도 메 인 이름 은 특정한 service 에 대응 합 니 다. 즉, 특정한 도 메 인 이름 의 요청 이 들 어 왔 을 때 특정한 service 에 전달 합 니 다.이 규칙 은 Ingress Controller 와 결합 한 다음 에 Ingress Controller 는 부하 이퀄 라이저 설정 에 동적 으로 기록 하여 전체적인 서비스 발견 과 부하 균형 을 실현 합 니 다.
좀 어 리 석 으 면 그림 을 보 세 요.
위의 그림 에서 볼 수 있 듯 이 실제 요청 이 들 어 왔 는 지 부하 이퀄 라이저 에 의 해 차단 되 었 는 지, 예 를 들 어 nginx, 그리고 Ingress Controller 는 Ingress 와 의 상호작용 을 통 해 특정한 도 메 인 이름 이 어떤 service 에 대응 하 는 지 알 수 있 고, kubernetes API 와 의 상호작용 을 통 해 service 주소 등 정 보 를 알 수 있다.종합 후 설정 파일 을 생 성하 여 부하 균형 기 에 실시 간 으로 기록 한 다음 에 부하 균형 기 reload 이 규칙 은 서비스 발견, 즉 동적 매 핑 을 실현 할 수 있다
상기 내용 을 알 게 된 후에 이것 은 내 가 왜 부하 균형 기 를 Daemon Set 로 배치 하 는 것 을 좋아 하 는 지 잘 설명 했다.어쨌든 요청 은 우선 부하 균형 기 에 의 해 차단 되 었 기 때문에 모든 노드 에 배치 하고 hostport 방식 으로 80 포트 를 감청 합 니 다.그러면 다른 방식 으로 부하 이퀄 라이저 가 어디 에 있 는 지 확인 하지 못 하 는 문 제 를 해결 하고 모든 node 의 80 을 방문 하면 요청 을 정확하게 해석 할 수 있 습 니 다.전단 에 nginx 를 하나 더 놓 으 면 부하 균형 이 다시 이 루어 집 니 다.
2. Traefik 사용
마이크로 서비스 구조 와 Docker 기술 과 kbenetes 편성 도구 가 최근 몇 년 에 야 유행 하기 시 작 했 기 때문에 처음에 역방향 프 록 시 서버, 예 를 들 어 nginx, apache 는 지원 을 제공 하지 않 았 습 니 다. 그들 도 선지 자가 아니 었 기 때 문 입 니 다.그래서 Ingress Controller 라 는 것 이 나 타 났 습 니 다.즉, Ingress Controller 의 존 재 는 바로 kubernetes 와 상호작용 을 할 수 있 고 nginx 설정 도 쓸 수 있 으 며 reload 도 할 수 있 습 니 다. 이것 은 절충 방안 입 니 다.최근 에 등장 한 traefik 은 천성적으로 kubernetes 에 대한 지원 을 제공 했다. 즉, traefik 자체 가 kubernetes API 와 상호작용 을 하고 백 엔 드 변 화 를 감지 할 수 있 기 때문에 traefik 을 사용 할 때 Ingress Controller 는 이미 쓸모 가 없 기 때문에 전체적인 구 조 는 다음 과 같다.
2.1 Traefik 배치
이미 대체적으로 Ingress 와 traefik 을 알 게 되 었 으 니 배치 하기 가 매우 간단 하 다.
2.1.1 Daemon Set 배치
우선 Daemon Set 방식 으로 모든 node 에 traefik 을 시작 하고 hostPort 방식 으로 모든 node 의 80 포트 를 감청 하도록 합 니 다.

kubectl create -f traefik.ds.yanl

# Daemon set     
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: traefik-ingress-lb
  namespace: kube-system
  labels:
    k8s-app: traefik-ingress-lb
spec:
  template:
    metadata:
      labels:
        k8s-app: traefik-ingress-lb
        name: traefik-ingress-lb
    spec:
      terminationGracePeriodSeconds: 60
      hostNetwork: true
      restartPolicy: Always
      containers:
      - image: traefik
        name: traefik-ingress-lb
        resources:
          limits:
            cpu: 200m
            memory: 30Mi
          requests:
            cpu: 100m
            memory: 20Mi
        ports:
        - name: http
          containerPort: 80
          hostPort: 80
        - name: admin
          containerPort: 8580
        args:
        - --web
        - --web.address=:8580
        - --kubernetes

그 중에서 traefik 감청 node 의 80 과 8580 포트, 80 은 정상 적 인 서 비 스 를 제공 합 니 다. 8580 은 자체 적 인 UI 인터페이스 입 니 다. 원래 기본 값 은 8080 입 니 다. 환경 에서 포트 가 충돌 하기 때문에 여 기 를 임시로 바 꿉 니 다.
2.1.2 Ingress 배치
위의 긴 사설 에서 인 그 레 스 컨트롤 러 는 배치 할 필요 가 없다 는 것 을 알 았 기 때문에 인 그 레 스 를 직접 배치 하면 된다.

kubectl create -f traefik.ing.yaml

# Ingress     
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: traefik-ingress
spec:
  rules:
  - host: traefik.www.test.com
    http:
      paths:
      - path: /
        backend:
          serviceName: test-www
          servicePort: 8080
  - host: traefik.api.test.com
    http:
      paths:
      - path: /
        backend:
          serviceName: test-api
          servicePort: 8080

실제 사전 클 러 스 터 에는 test - ww 와 test - api 라 는 service 가 존재 하고 해당 하 는 service 백 엔 드 에 도 pod 가 많 습 니 다.따라서 실제 업무 용기 (test - ww, test - api) 를 배치 하 는 과정 을 구체 적 으로 쓰 지 않 습 니 다. 여러분 이 테스트 할 때 이 test 의 서 비 스 를 자신의 업무 서비스 로 교체 하면 됩 니 다.
2.1.3 Traefik UI 배치
traefik 자체 가 사용 할 수 있 도록 UI 를 제공 합 니 다. 같은 Ingress 방식 으로 노출 되 었 습 니 다. 만 들 기만 하면 됩 니 다.

kubectl create -f ui.yaml

# ui yaml   
---
apiVersion: v1
kind: Service
metadata:
  name: traefik-web-ui
  namespace: kube-system
spec:
  selector:
    k8s-app: traefik-ingress-lb
  ports:
  - name: web
    port: 80
    targetPort: 8580
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: traefik-web-ui
  namespace: kube-system
spec:
  rules:
  - host: traefik-ui.local
    http:
      paths:
      - path: /
        backend:
          serviceName: traefik-web-ui
          servicePort: web

2.1.4 방문 테스트
모두 만 든 후, 테스트 를 기다 리 는 도 메 인 이름 을 임의의 node 에 분석 하면 됩 니 다. 페이지 는 캡 처 하지 않 고 캡 처 하면 노출 됩 니 다........................................................
2.2 건강 검진
건강 검진 에 대해 서 는 kubernetes 의 Liveness Probe 를 사용 하여 테스트 할 수 있 습 니 다. Liveness Probe 검사 에 실패 하면 traefik 은 이 pod 를 자동 으로 제거 합 니 다. 다음은 예제 입 니 다.
test 의 deployment, 건강 검진 방식 은?  cat /tmp/health 용기 가 시 작 된 지 2 분 후에 이 파일 을 삭제 하고 건강 검진 에 실 패 했 습 니 다.

apiVersion: v1
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: test
  namespace: default
  labels:
    test: alpine
spec:
  replicas: 1
  selector:
    matchLabels:
      test: alpine
  template:
    metadata:
      labels:
        test: alpine
        name: test
    spec:
      containers:
      - image: mritd/alpine:3.4
        name: alpine
        resources:
          limits:
            cpu: 200m
            memory: 30Mi
          requests:
            cpu: 100m
            memory: 20Mi
        ports:
        - name: http
          containerPort: 80
        args:
        command:
        - "bash"
        - "-c"
        - "echo ok > /tmp/health;sleep 120;rm -f /tmp/health"
        livenessProbe:
          exec:
            command:
            - cat
            - /tmp/health
          initialDelaySeconds: 20

테스트 서비스

apiVersion: v1
kind: Service
metadata:
  name: test 
  labels:
    name: test
spec:
  ports:
  - port: 8123
    targetPort: 80
  selector:
    name: test

test 의 Ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
spec:
  rules:
  - host: test.com
    http:
      paths:
      - path: /
        backend:
          serviceName: test
          servicePort: 8123

모두 만 든 후, traefik ui 인터페이스 에 들 어가 면 2 분 간격 으로 건강 검진 에 실패 한 후, kubernetes 가 pod 를 재 구축 하 는 것 을 관찰 할 수 있 으 며, traefik 은 백 엔 드 목록 에서 이 pod 를 제거 합 니 다.
기타 더 많은 게임 방법 참고 하 세 요 공식 문서 (Let 's Entrypt, 개인 블 로그 복음 을 지지 하 는 것 을 발 견 했 습 니 다) 오류 가 있 으 면 지적 을 환영 합 니 다.