#title Kubernetes
#keywords kubernetes, container

[[TableOfContents]]

== 서비스 디스커버리 ==
=== 쿠버네티스에서 서비스 디스커버리를 구현하는 다양한 방법 ===
1. ClusterIP
2. ExternalName
3. NodePort
4. LoadBalancer
5. Ingress

=== 인그레스 ===
인그레스(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. 노드에서 시크릿은 tmpfs의 메모리에 저장되며, 실제 스토리지에는 기록되지 않고 파드가 제거될 때 함께 제거된다.
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(VerticalPodAutoscaler)]](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나 메모리를 충족시키는 용량을 갖춘 노드가 없다면 새로운 노드를 프로비전 한다. 최소 노드 수와 최대 노드 수가 설정되어야 한다.

== Tips ==
=== 파드 내 네임스페이스 확인 ===
{{{#!vim ruby
dat, err := ioutil.ReadFile("/var/run/secrets/kubernetes.io/serviceaccount/namespace")
if err != nil {
	panic(err)
}
fmt.Print(string(dat))
}}}

=== Kubernetes YAML 자원 추가 삭제 ===
Q: kubectl로 yaml을 변경해서 자원을 변경/추가하면, 기존 yaml에 있던 자원들은 삭제되는거야 아니면 유지된 상태로 있는거야?
ChatGPT:
`kubectl`을 사용하여 YAML 파일을 변경하면, 해당 파일에서 수정된 자원만 변경되고, 나머지 자원들은 변경되지 않습니다. 즉, 기존 YAML 파일에 있던 자원들은 변경되지 않고 유지됩니다.

예를 들어, 기존 YAML 파일에 `Deployment`와 `Service` 자원이 있고, `kubectl apply -f` 명령어를 사용하여 새로운 `ConfigMap` 자원을 추가한다고 가정해 봅시다. 이 경우, `Deployment`과 `Service` 자원은 변경되지 않고 그대로 유지되며, 새로운 `ConfigMap` 자원만 추가됩니다.

그러나, 만약 YAML 파일에서 기존 자원을 삭제하거나 수정하는 경우 해당 자원은 삭제되거나 수정됩니다. 따라서, 자원을 수정할 때는 반드시 변경하고자 하는 자원만을 수정하는지 확인해야 합니다.

Q: 그렇다면 kubectl로 특정 자원만 지우는 방법은 무엇이 있지? 예를 들어 Service 자원을 지우고 싶을 때.
ChatGPT:
`kubectl delete` 명령어를 사용하여 특정 자원을 삭제할 수 있습니다. 예를 들어, `Service` 자원을 삭제하려면 다음 명령어를 사용할 수 있습니다:

{{{#!arduino
kubectl delete service <service-name>
}}}

여기서 `<service-name>`은 삭제하려는 `Service` 자원의 이름입니다. 이 명령어를 실행하면 해당 `Service` 자원이 삭제됩니다.

만약, YAML 파일을 사용하여 `Service` 자원을 생성했다면, 해당 YAML 파일을 편집하여 `Service` 자원을 삭제하거나, 다음 명령어를 사용하여 YAML 파일에서 `Service` 자원을 삭제하고 적용할 수 있습니다:

{{{#!arduino
kubectl delete -f <yaml-file>
}}}

여기서 `<yaml-file>`은 삭제하려는 `Service` 자원이 포함된 YAML 파일의 경로입니다. 이 명령어를 실행하면 해당 YAML 파일에서 `Service` 자원이 삭제되고, 변경 사항이 Kubernetes 클러스터에 적용됩니다.

Q: kubectl delete namespace <namespace-name>로 네임스페이스를 지우면 네임스페이스 안에 있던 자원들은 깔끔하게 지워지나?
ChatGPT:
네, `kubectl delete namespace <namespace-name>` 명령어를 사용하여 네임스페이스를 삭제하면 해당 네임스페이스 안에 있는 모든 자원들이 함께 삭제됩니다.

기본적으로, 네임스페이스를 삭제하면 해당 네임스페이스 내부에 있는 모든 Kubernetes 자원(예: Pod, Deployment, Service 등)이 자동으로 삭제됩니다. 그러나 만약에 네임스페이스 안에 다른 네임스페이스가 있거나, 다른 네임스페이스를 참조하는 Kubernetes 자원이 있다면, 이러한 자원들은 삭제되지 않을 수 있습니다.

따라서, `kubectl delete namespace` 명령어를 사용하기 전에, 해당 네임스페이스에 어떤 자원들이 있는지 확인하고, 필요한 경우 해당 자원들을 먼저 삭제해 주는 것이 좋습니다.

=== Well-Known Labels을 임의로 지워도 되나? ===
Q: K8S의 Well-Known Labels들(예를 들어 node.kubernetes.io/instance-type과 같은)은 언제 생성되는 거지? 함부로 지우면 안되겠지?
ChatGPT:
Kubernetes에서 Well-Known Labels은 Kubernetes 자체와 관련된 정보를 제공하는 레이블입니다. 이러한 레이블은 시스템 구성 요소와 관련된 정보를 포함하고 있으므로 Kubernetes에서 자동으로 생성됩니다.

예를 들어, `node.kubernetes.io/instance-type` 레이블은 노드 인스턴스 유형과 관련된 정보를 포함하고 있습니다. 이 레이블은 AWS, GCE, Azure 등의 클라우드 제공업체에서 자동으로 생성되며, 노드 유형과 연결된 정보를 포함합니다.

일반적으로 이러한 Well-Known Labels은 시스템에서 자동으로 생성되므로, 삭제하면 Kubernetes의 일부 기능이 영향을 받을 수 있습니다. 예를 들어, `kubernetes.io/hostname` 레이블은 각 노드의 호스트 이름을 포함하고 있으며, 이 레이블이 없으면 Kubernetes에서 노드를 식별할 수 없습니다.

따라서 Well-Known Labels을 함부로 지우면 안됩니다. 이러한 레이블은 Kubernetes 시스템 구성의 일부이며, 시스템 구성 요소와 상호 작용하는 데 필요합니다. 필요한 경우 이러한 레이블을 수정할 수는 있지만, 삭제하면 안됩니다.

----
CategoryDev