#title Kubernetes
#keywords kubernetes, container

[[TableOfContents]]

== 서비스 디스커버리 ==
=== 인그레스 ===
인그레스(Ingress)는 서비스 앞쪽에 위치하며 스마트 라우터 및 클러스터 엔트리 포인트 역할을 하는 별도의 쿠버네티스 자원이다. 인그레스는 외부에서 접근 가능한 URL, 로드 밸런싱, SSL 종료, 이름 기반 가상 호스팅 등을 통해 서비스에 대한 HTTP 기반 접근을 제공한다.

{{{
apiVersion: extentions/v1beta1
kind: Ingress
...
spec:
  backend:
    serviceName: ...
    servicePort: 8080
}}}

인그레스는 쿠버네티스에서 가장 강력하고 동시에 가장 복잡한 서비스 디스커버리 메커니즘이다.

== 설정 자원 ==
=== EnvVar ===
설정을 외부화 하는 가장 쉬운 방법은 도커의 ENV 지시자나 도커파일에서 직접 정의할 수 있는 환경 변수에 설정 값을 배치하는 것이다. 쿠버네티스는 디플로이먼트 또는 레플리카세트 같은 컨트롤러의 파드 명세에서 직접 설정할 수 있다.

{{{
...
spec:
  containers:
  ...
    env:
    - name: ...
      value: ...
}}}

EnvVar는 소규모의 변수와 간단한 설정에만 적합하다. 또, 어디에 변수가 정의되어 있는지 찾기 어렵다는 단점도 있다. 쿠버네티스는 단순 환경 변수보다 훨씬 유연한 전용 설정 자원인 컨피그맵(ConfigMap), 시크릿(Secret) 객체를 제공한다.

=== 컨피그맵 ===
{{{
apiVersion: v1
kind: ConfigMap
metadata:
  name: ...
data:
...
}}}

==== 컨피그맵에 설정된 환경 변수 세트 ====
{{{
...
spec:
  containers:
  - env:
    - name: ...
      valueFrom:
        configMapKeyRef:
          name: ...
          key: ...
}}}

{{{
...
spec:
  containers:
    envFrom:
    - configMapKeyRef:
      name: ...
}}}

==== 컨피그맵을 볼륨으로 마운트 ====
{{{
...
spec:
  containers:
  ...
  volumes:
  - name: config-volume
    configMap:
      name: ...
}}}


=== 시크릿 ===
컨피그맵 대신 시크릿에 접근하려면 [[Code(configMapKeyRef)]]를 [[Code(secretKeyRef)]]로 바꾸자.

==== 시크릿은 얼마나 안전한가? ====
시크릿은 데이터를 Base64로 인코딩해 가지고 있다가 환경 변수나 마운트된 볼륨으로 파드에 전달하기 전에 디코딩된다. 간혹 시크릿을 보안 기능으로 착각하기도 하지만 Base64는 암호화 기법이 사용된 인코딩이 아니며 보안 측면에서 평문 텍스트와 동일하다. 그렇다면 왜 시크릿이 컨피그맵보다 안전하다고 할까? 시크릿은 보안을 유지하기 위한 구현 세부사항이 많다. 끊임없이 개선이 이루어지는 중이지만 현재 시점에서는 크게,

1. 시크릿은 자신에게 접근한 파드가 실행 중인 노드에만 배포된다.
2. 노드에서 시크릿은 tmsfs의 메모리에 저장되며, 실제 스토리지에는 기록되지 않고 파드가 제거될 때 함께 제거된다.
3. 시크릿은 etcd에 암호화된 형태로 저장된다.

이런 주요 구현과 상관없이 루트 사용자로 시크릿에 접근하거나, 파드를 생성해서 시크릿에 마운트하는 등 다양한 방법으로 시크릿을 읽을 수 있다. 따라서 민감한 정보는 애플리케이션 레벨에서 추가 암호화가 필요하다.

== 스케일링 ==
=== 수평 스케일링과 수직 스케일링의 차이 ===
애플리케이션을 스케일링하는 것에는 2가지 주요 접근 방법이 있다.

1. 수평 스케일링
쿠버네티스에서 수평으로 스케일하는 것은 파드 레플리카를 더 많이 만드는 것이다.

2. 수직 스케일링
수직으로 스케일하는 것은 파드가 관리하는 컨테이너를 실행하는 데 더 많은 자원을 제공하는 것이다.

※ 설명으로는 간단해 보이지만, 다른 서비스와 클러스터 자체에 영향을 미치지 않도록 오토스케일링을 위한 애플리케이션 설정을 생성하려면 상당한 시행착오를 거쳐야 한다.

=== 수동 수평 스케일링 ===
이름에서 알 수 있듯이 쿠버네티스 운영자를 기반으로 최적의 설정을 점진적으로 튜닝한다. 오토스케일링이 없는 경우나 느리게 변화하는 로드를 처리하는 애플리케이션의 경우 사용할 수 있다. 자주 변경되고 적응이 필요한 동적 워크로드 패턴에는 적합하지 않다.

=== 수평 파드 오토스케일링 ===
고정되어 있지 않으면서도 로드를 충분히 처리할 수 있는 용량을 보장하는 애플리케이션 용량을 정의할 수 있다. 가장 간단한 방법은 [[Code(HorizonPodAutoscaler)]](HPA)를 사용해 파드의 수를 수평으로 스케일하는 것이다.

{{{
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
...
spec:
  minReplicas: 1
  maxReplicas: 5
  scaleTargetRef:
    apiVersion: extentions/v1beta1
    kind: Deployment
...
}}}
https://t1.daumcdn.net/cfile/tistory/992DD43A5D5C028303&.jpg
그림. 수평 파드 오토스케일링의 메커니즘

=== 수직 파드 오토스케일링 ===
수평 스케일링은 스테이트리스 서비스에 지장을 덜 주기 때문에 수직 스케일링보다 선호되지만, 수직 스케일링은 실제 로드 기반으로 서비스의 실제 자원 요구를 튜닝할 때 유용하다.

파드의 모든 컨테이너는 CPU와 메모리 requests를 지정할 수 있으며 특정한 양의 자원을 보장한다. 즉 자원이 보장되지 않으면 파드가 스케줄되지 않는다. 메모리 요청을 너무 낮게 잡으면 노드가 더욱 꽉 채워지기 때문에 메모리 압박으로 메모리 부족 오류로 워크로드 축출이 일어날 수 있다. CPU limits를 너무 낮게 잡으면 CPU 고갈이나 성능이 저하된 워크로드가 발생할 수 있다. 반면에 너무 많은 자원을 requets하면 불필요한 용량이 할당되어 자원이 낭비된다. 클러스터의 사용률과 수평 스케일링의 효율성을 위해 가능한 정확하게 자원을 요청하는 것이 중요하며 [[Code(Vertical Pod Autoscaler)]](VPA)가 이를 해결하는데 도움이 되며 실제 사용 피드백을 기반으로 자원을 조정 및 할당하는 과정을 자동화한다.

{{{
apiVersion: poc.autoscaling.k8s.io/v1alpha1
kind: VerticalPodAutoscaler
...
spec:
  selector:
    matchLables:
       app: ...
  updatePolicy:
    updateMode: "Off"
}}}

※ VPA와 HPA를 함께 사용하는 것은 오토스케일러가 아직까지는 서로를 인식하지 않아 원치 않은 동작이 발생될 수 있다. VPA는 아직 베타버전이며 향후 활발히 사용되면 변경될 가능성도 있다.
그러나 여전히 VPA는 자원 소비 효율성을 크게 향상 시킬 가능성이 있는 기능이다.

=== 클러스터 오토스케일링 ===
새로운 노드를 스케일링한다. 쿠버네티스가 클라우드 컴퓨팅 인프라스트럭처상에서 실행 중일 때만 수행될 수 있다. 모든 주요 클라우드 제공업체는 쿠버네티스 오토스케일러(CA)를 제공한다. HPA와 VPA의 스케일링 기술은 클러스터 용량 한도 내에서만 탄력성을 제공한다. CA는 쿠버네티스 애드온으로 구동되고 요청된 CPU나 메모리를 충족시키는 용량을 갖춘 노드가 없다면 새로운 노드를 프로비전 한다. 최소 노드 수와 최대 노드 수가 설정되어야 한다.
----
CategoryDev