7. Namespace, ResourceQuota, LimitRange & 실습

개요

 쿠버네티스 클러스터라 해서 전체가 사용할 수 있는 자원이 있습니다. 일반적으로 메모리, CPU가 있을거고, 클러스터 안에는 여러 네임스페이스들을 만들 수 있고, 네임 스페이스 안에는 여러 Pod를 만들 수 있습니다. 각 Pod는 클러스터 자원을 공유해서 사용하는데, 만약 한 네임스페이스 안에 있는 Pod가 클러스터에 남은 자원을 모두 사용하면 다른 Pod 입장에서는 더 이상 쓸 자원이 없어서 자원이 필요할 때 문제가 발생하게 됩니다.

 

 이런 문제를 해결하기 위해 네임 스페이스마다 ResourceQuota를 달면 최대 한계를 지정할 수 있습니다. Pod가 한계를 넘을 수 없고, Pod 입장에서 자원이 부족해 문제가 될지언정 다른 네임 스페이스에 있는 Pod에는 영향을 끼치지 않게 해줍니다. 한 Pod가 자원 사용량을 너무 크게하면 다른 Pod가 이 네임 스페이스에 들어올 수 없게 됩니다. 그래서 Limit Range를 둬서 네임 스페이스에 들어오는 Pod 크기를 지정할 수 있습니다. 한 Pod의 자원 사용량이 Limit Range 설정된 값 보다 낮아야지 위 네임 스페이스에 들어올 수 있습니다. 또한 Resource Quota, LimitRange는 네임 스페이스 뿐만 아니라 클러스터에도 달아서 전체 자원에 대한 제한을 걸 수 있습니다.

 

 

 

 

1. Namespace

 : 한 Namespace 안에는 같은 타입의 오브젝트들 이름이 중복될 수 없습니다.오브젝트마다 별도의 UUID가 존재하지만, 이름이 중복되면 안됩니다. 또한 타 네임스페이스에 있는 자원과 분리가 되는 특징이 있는데, 위 그림에서 다른 네임 스페이스가 있고, 그 안에는 서비스가 존재합니다. 우리는 이 Pod와 서비스 간의 연결을 파드에는 라벨을 달고 서비스에는 셀렉터를 달아서 연결을 합니다. 하지만 타 네임스페이스에 있는 파드에는 연결이 되지 않습니다. 지금까지 배웠던 자원들은 네임스페이스 내에서만 만들 수 있습니다. 예외는 노드와 PV 같이 모든 네임 스페이스에서 공용으로 사용되는 오브젝트가 있습니다. 추가로 네임스페이스를 지우게 되면 안에 있는 자원들도 모두 지워지게 됩니다.

 

 

2. ResourceQuota

 : 네임스페이스의 자원을 한계하는 오브젝트 입니다. 중요한 점은 ResourceQuota가 지정되어 있는 네임스페이스에 파드를 만들 때 이 Pod는 스펙을 명시해야 합니다. 메모리 뿐만 아니라 Cpu, storage도 제한할 수 있습니다. 그리고 오브젝트들의 숫자도 제한할 수 있는데, 많은 오브젝트들이 있지만 모든 오브젝트들을 다 제한할 수 있는 건 아니고, 점점 늘어나고 있습니다. 그래서 현재 버전에서 어느 정도 까지 제한할 수 있는지 알아야 할 것입니다.

 

 

3. LimitRange

 : 각각의 Pod마다 네임 스페이스에 들어올 수 있는지 자원을 체크해줍니다. 체크 항목으로 min, max, maxLimitRequestRatio가 있습니다. min은 파드에서 설정되는 메모리의 리미트 값이 1GB가 넘어야하고, Max는 4GB를 넘으면 안되고, maxLimitRequestRatio는 3을 설정하게 되면 Request, Limit 값의 비율이 최대 3배를 넘으면 안된다는 뜻입니다. 

 

 

 

실습

 1. Namespace 실습

(1)같은 이름의 Pod는 생성 X

 

 

(2) 또한 Namespace 새로 생성한 후 여기에 Service, Pod를 다시 생성합니다. 이번에는 Namespace를 지정하지 않고 해볼건데 그 결과 아래 그림과 같이 앞에서 만들었던 Pod는 연결이 되지않고 1개만 연결이 되어 있는것을 통해 라벨과 셀렉터는 같은 네임스페이스에서만 유효한 것을 확인할 수 있습니다.

 

 

 

(3) 위는 nm-2 네임 스페이스에서 nm-1의 Pod와 Service에 접근에 성공한 것을 볼 수 있는데, 이는 네임 스페이스가 IP 접근을 막아주지 않는 다는 것을 알 수 있습니다. 네트워크 폴리시라는 오브젝트가 그 역할을 도와준 것 입니다.

 

 

 

(4) 이번에는 NodePort인데 역시 네임 스페이스로는 나눌 수 없습니다. 같은 포트로 설정하면 provided port is already allocated라는 문구로 설정되었기에 위처럼 다르게 해줘야 합니다. 

 

 

 

(5) 위는 nm-1 에서 hostPath 사용해서 hello.txt 파일을 만들고, nm-2에서 해당 /mount1로 접근해보면 파일이 존재하는 것을 확인할 수 있습니다. 기본적으로 Pod의 권한을 root로 사용하기 때문에 유저 권한을 주도록 변경이 필요한 부분입니다. 그래서 주의할 내용은 네임 스페이스의 분리 기능에 대해 기본적으로 제공하는 기능과 못하는 기능, 추가적인 object를 통해 분리 설정해야 하는 부분이기에 이런 것을 잘 확인하고 사용해야 합니다.

 

 

 

2. ResourceQuota

 

 Dashboard에서는 확인이 안되고, 명령어를 통해 확인해야 합니다. 만약 리소스 커터가 적용되어 있는 네임 스페이스에 이 Pod를 만들 때 리소스 부분을 빼고 만들게 되면 반드시 명시하라고 경고가 나옵니다. 또한 리소스 커터의 제한되어 있는 양을 넘으면 경고 메세지가 표시 됩니다. 또한 Pod 개수를 제한할 수 있는데, 이 또한 초과해서 생성하려고 하면 에러 문구가 나옵니다.

 

 주의해야 할 점으로 네임 스페이스에 리소스 커타를 달면 Pod에 사용할 자원을 명시해야 했는데요. 리소스 커터가 만들기 전에 해당 네임 스페이스에 Pod가 존재하지 않도록 해야하는 것이 중요합니다. 왜냐하면 자원을 명시한 리소스 커터를 무시하고 Pod의 생성과 메모리를 생성할 수 있기 때문입니다.

 

 

 

3. LimitRange

 

 이 또한 명령어를 통해 확인해야 합니다. 만약 LimitRange에서 설정한 값보다 큰 Pod의 limit와 Request 비율을 생성하려고 하면 위처럼 에러 문구가 나오는 것을 볼 수 있습니다.

 

 

 또한 requests를 적용하지 않고 pod를 생성한다면 LimitRange에서 적용한 0.2Gb, 0.1GB 이렇게 default로 설정한 부분이 자동으로 적용된 것을 볼 수 있습니다. 주의해야 할 점으로는 한 네임 스페이스에 여러개의 LimitRange를 적용하면 예상치 못한 동작에 의해 Pod가 생성이 안될 수 있습니다.