[컴] 쿠버네티스 configuration best practices

kubernetes / 컨피그 / 설정 / 베스트 프랙티스/ 모범 / 최선

쿠버네티스 configuration best practices

ref.1 의 내용을 일부 적었다. 자세한 것은 ref.1 을 참고하자.

일반적인 팁들

  • 최근 stable API version 을 적자
  • version control 에 저장하자. 나중에 roll back 을 빠르게 할 수 있고, 다른 곳에서 만들때도 좋다.
  • JSON 보다 YAML 을 쓰자. 좀 더 직관적이다.
  • 하나의 group 과 관련된 object 들은 하나의 file 에 넣자. 관리가 용이하다. 예제
  • 많은 kubectl 명령어들이 directory 에서 호출될 수 있다.는 것을 기억하자.(?)
  • 불필요한 기본값을 적지 말자. 간략한 것이 에러를 적게 만든다.
  • annotation 안에 object 설명을 넣자. 더 나은 검토(introspection)를 가능하게 해준다.

Naked Pods

  • 되도록 naked Pods 를 사용하지 말자.
    • naked pods 는 pod 가 ReplicaSet 이나 Deployment 에 묶여 있지 않은 Pod 를 이야기 한다.
    • naked pods 는 node failure 상황에서 rescheduled 가 안된다.
    • Pods 를 만들기 위해 Deployment 를 사용하는 것이 선호된다. Job 도 적절할 수 있다.

Services

  • 쿠버네티스가 container 를 실행할때, 모든 살아있는 Services(running Services) 에 대한 환경변수를 container 에 제공한다.

    만약 A라는 Service 가 container 를 실행할 때 running 하고 있다면, 실행된 모든 container 들은 다음 변수를 갖게 된다.

    Pod 가 access 하고 싶은 Service 가 있다면, Pod 가 생성되기 전에 Service 가 생성되야 한다.

A_SERVICE_HOST=xxx.xx.x.x
A_SERVICE_PORT=xxxx
  • 꼭 필요한 경우가 아니면, Pod에 hostPort 를 적지말아라

    이것은 Pod 가 scheduled 될 수 있는 곳을 제한한다. 왜냐하면, <hostIP, hostPort, protocol> 조합은 unique 해야만 하기에, hostPort 가 명시되면 unique 한 값을 갖게되는 기회가 줄어든다.(이미 port 가 할당되어 버릴 수 있다.)

    hostIPprotocol 은 명시되어 있지 않으면, 쿠버네티스는 0.0.0.0TCP 를 기본값으로 사용한다.

    debugging 용도라면 apiserver proxykubectl port-forward 를 사용하자

    node 에서 Pod의 port 를 노출할 필요가 있다면, NodePort 를 고려해 보자.

  • hostNetwork 사용을 피하자. hostPort 와 같은 이유다.

  • kube-proxy load balancing 이 필요치 않을 때, service discovery 를 위해서는 headless Service 를 사용하자.

kubectl 사용

그 외

Reference

  1. Configuration Best Practices | Kubernetes
  2. 구성 모범 사례 | Kubernetes

댓글 없음:

댓글 쓰기