밝은숲

1. cgroup

cgroup 이란 cpu, memory 등 리소스를 제한/관리하는 리눅스 커널의 기능이며,

리눅스 커널은 cgroup v1, cgroup v2 두 가지 버전의 cgroup을 제공합니다.

cgroup v2는 2016년부터 리눅스 커널에서 개발되어 왔으며,

K8s v1.25 버전부터 cgroup v2 기능이 GA (general availability) 되었습니다.

cgroup v2에서 향상된 기능은 아래와 같습니다.

• API의 단일 통합 계층 설계
• 컨테이너에 대한 더 안전한 하위 트리 위임
• Pressure Stall Information 와 같은 최신 기능
• 향상된 리소스 할당 관리 및 여러 리소스 간 격리
  • 다양한 유형의 메모리 할당(네트워크 및 커널 메모리 등)에 대한 통합 계정
  • 페이지 캐시 쓰기 되돌림과 같은 즉각적이지 않은 리소스 변경에 대한 설명

일부 Kubernetes 기능은 향상된 리소스 관리 및 격리를 위해 cgroup v2를 독점적으로 사용합니다. 예를 들어 MemoryQoS 기능은 메모리 활용도를 개선하고 이를 활성화하기 위해 cgroup v2 기능에 의존합니다. kubelet의 새로운 리소스 관리 기능은 앞으로 나아가는 새로운 cgroup v2 기능을 활용할 것입니다.

Ubuntu 21.10 버전부터 cgroup v2가 기본으로 설정되어있지만, 이하 버전에서도 커널 5.8 이상(권장)에서 cgroup v2를 사용하도록 설정할 수 있습니다.

Ubuntu 20.04에서 설정방법

### cgroup v2 사용설정 방법
1. systemd.unified_cgroup_hierarchy=1 옵션 추가
/etc/default/grub 파일의 [grep GRUB_CMDLINE_LINUX=""] 항목에 옵션 추가
-> GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=1"


2. grub 업데이트
$ update-grub


3. 재기동
$ reboot


### 확인방법
1.
root@k8s-worker02:~# stat -c %T -f /sys/fs/cgroup
cgroup2fs

# 결과가 cgroup2fs이면 cgroupv2를 사용하는 것
# 결과가 tmpfs이면 cgroupv1을 사용하는 것


2.
아래 파일이 있으면, cgroupv2를 사용하는 것
root@k8s-worker02:~# ls -l /sys/fs/cgroup/cgroup.controllers
-r--r--r-- 1 root root 0 Mar  7 01:20 /sys/fs/cgroup/cgroup.controllers

참고)

https://sleeplessbeastie.eu/2021/09/10/how-to-enable-control-group-v2/

https://kubernetes.io/docs/concepts/architecture/cgroups/#check-cgroup-version

https://kubernetes.io/blog/2022/08/31/cgroupv2-ga-1-25/

2. MemoryQoS

MemoryQoS는 k8s v1.22에서 추가된 기능으로 현재까지 alpha 단계입니다.

K8s feature-gate 옵션으로 활성화하여 사용 할 수 있습니다.

cgroup v1에서는 cpu_share, cpu_set, cpu_quota, cpu_period와 같이 CPU 리소스만 제한할 수 있으며, MemoryQoS는 사용할 수 없으며, cgroup v2에서는 memoryQoS 기능을 지원합니다.

• 파드 및 컨테이너 메모리 요청 및 제한에 대한 메모리 가용성에 대한 보장을 제공합니다.
• 노드 리소스의 메모리 가용성에 대한 보장 제공
• 파드 및 컨테이너 수준 cgroup에 대한 새로운 cgroup v2 memory knobs(memory.min/memory.high) 사용
• 노드 레벨 cgroup에 대한 새로운 cgroup v2  memory knobs(memory.min) 사용

memory.high 계산 방법

[k8s v1.22]

requests.memory=50, limits.memory=100 경우 조절 계수 0.8을 곱하여 memory.high=80이 됩니다.

throttling factor = 0.8

memory.high=(limits.memory or node allocatable memory) * memory throttling factor, 
where default value of memory throttling factor is set to 0.8

[k8s v1.27]

컨테이너 메모리 제한이 지정되지 않은 경우 조절 계수 0.9를 곱하여 적용됩니다.

throttling factor = 0.9

memory.high=floor[(requests.memory + memory throttling factor * (limits.memory or node allocatable memory - requests.memory))/pageSize] * pageSize, where default value of memory throttling factor is set to 0.9

k8s v1.25에서 MemoryQoS 활성화 방법

# MemoryQoS 활성화
/etc/kubernetes/kubelet-config.yamlS에 아래 옵션 추가 후 kubelet 재기동
...
featureGates:
  MemoryQoS: true
...


#확인방법
root@k8s-worker02:~# ctr -n k8s.io c info 8b9e8c3f8815425dafea3530281fb967c23f97acd2a83009708b9ce46a6755c4 | grep memory
                "memory": {
                    "memory.high": "107374182",
                    "memory.min": "67108864"
                    
 
 
*kubespray에서 설정방법
vi ~/roles/kubespray-defaults/defaults/main.yaml
kubelet_feature_gates: []
-> kubelet_feature_gates: [MemoryQoS=true]

*cgroup v2를 사용해야 MemoryQoS를 활성화 할 수 있습니다.

참고)

https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2570-memory-qos/#readme

https://kubernetes.io/blog/2021/11/26/qos-memory-resources/

추가

*MemoryQoS 기능 활성화 후 비정상적인 부하 증가로 인하여, 기능 disable 함.

OPA란?

 - Open Policy Agent의 약어

 - OPA는 플랫폼 관리자에게 세밀한 권한 관리를 할 수 있도록 지원하는 범용 정책 엔진으로 K8S 뿐 아니라 OPA 엔진을 이용하는 모든 플랫폼에서 사용 가능

(1) OPA 동작

 - 요청이 들어오면 서비스는 JSON을 이용하여 OPA에 허용 여부 질의
 - 질의를 받은 OPA는 저장된 Policy를 불러와서 요청에 대한 평가를 하고 결과를 다시 JSON 형식으로 서비스에 반환

(2) 정책 설정

 - OPA는 Policy를 기반으로하여 사용자 접근을 관리하기 때문에 Policy를 어떻게 작성하는지가 중요함
 - Policy는 Rego라는 자체 질의언어를 이용하여 작성해야 하며, Rego 언어가 선언적으로 동작하기 때문에 해당 문법에 대한 이해 필요

Gatekeeper 란?

 - 게이트키퍼는 내부적으로 OPA 엔진을 사용하는 OPA의 K8S 승인/제어를 위해 제작된 솔루션

(1) Gatekeeper 동작

 - K8S에서는 정책적인 결정을 API 서버와 분리하여 독립적으로 할 수 있게 Admission Controller Webhook (이하 웹훅) 제공
 - 웹훅은 클러스터가 변경될 때 무조건 실행되며, 게이트키퍼는 웹훅을 확인하여 OPA 정책 엔진에서 정의한 대로 실행

(2) 주요 기능

 Validating Admission Control
  - 웹훅을 트릭거로 OPA와 api-server 다리 역할을 하여 정책 적용
Policies and Constraints
  - Rego 언어로 작성되며 정의한 요구하상을 위반하는 리소스들을 확인
Audit
  - 배포된 자원을 정기적으로 감사하여 Constraints에 반하는 것이 있는지 확인
Data Replication
  - 리소스를 복제 한 후 감사가 진행되며, 복제할 수 있도록 권한 부여 필요

(3) Gatekeeper Library

 - 게이트키퍼에서는 K8S에서 일반적으로 사용하는 정책에 대한 샘플 제공

- Pod Security Policy의 설정을 게이트키퍼에서 제약조건 및 탬플릿을 배포하여 정책 설정 가능

(4) Gatekeeper Library 샘플 구조

 - OPA 정책에 대한 탬플릿 파일과 제약사항 정의파일 및 예제파일로 구성

(5) Gatekeeper Library 샘플

[allowedrepos]
 - 허용된 이미지 repositor만 사용하도록 설정

참고)

https://github.com/open-policy-agent/gatekeeper

1. 현상

- docker0 인터페이스 대역이 사내 서버 ip와 겹칠 경우 통신이 안되는 현상

2. 조치

2.1 OS에서 routing 설정으로 해결 가능

2.2 docker0 대역을 변경

(1) kubespray의 경우 docker.yml 파일에서 docker 옵션으로 변경 가능

...
docker_options: "--bip 192.168.0.1/16"

(2) 이미 클러스터가 배포되어 있는 경우

/etc/docker/daemon.json 파일 수정

{
    "bip":"192.168.0.1/16"
}

docker 재기동

# systemctl restart docker

*restart docker하면 바껴야 정정상데 vm 환경이라그런지 적용이 안되는 서버들이 있음. 여러번 restart 해서 적용이되기도 하는데... reboot하면 바로 해결

3. 확인

# ip a | grep docker0

############# 추가 ############# 

deamon.json 파일에 bip 옵션을 넣을 경우 클러스터 삭제/재생성이 제대로 되지 않음

-> 다른 파일에도 bip 옵션이 있어서 옵션 충돌이 남

deamon.json 파일이 아닌 /etc/systemd/system/docker.service.d/docker-options.conf 파일을 수정해야 함

csi-nfs-driverinfo.yaml에 옵션 추가

apiVersion: storage.k8s.io/v1beta1
kind: CSIDriver
metadata:
  name: nfs.csi.k8s.io
spec:
  attachRequired: false
  fsGroupPolicy: File     #옵션추가
  volumeLifecycleModes:
    - Persistent

1. 목적

 - deploy 서버에서 클러스터 context 획득

2. 스크립트

vi /opt/kube-cert/get_auth_file.sh

-----------------------------------------------------------------------

#!/bin/bash

if [[ $1 == "" || $2 == "" ]]; then
  echo "################################"
  echo "ex) "
  echo "./get_auth_file.sh CUSTER_NAME IP_ADDR"
  echo "./get_auth_file.sh test1 192.168.56.101"
  echo "################################"
  exit 0;
fi

echo "### Get Auth Files$$$"
scp $2:/etc/kubernetes/admin.conf $1-cluster-admin.conf
scp $2:/etc/kubernetes/pki/ca.crt $1-cluster-ca.crt
scp $2:/etc/kubernetes/ssl/apiserver-kubelet-clinet.crt $1-cluster-client.crt
scp $2:/etc/kubernetes/ssl/apiserver-kubelet-client.key $1-cluster-client.key

echo "###Change IP Address###"
sed -i "s/127.0.0.1/$2/g" $1-cluster-admin.conf

echo "###Copy ./kube/config ###"
cp -f ~/.kube/config .

echo "###Add New-Cluster Context###"
kubectl config set-cluster $1-cluster.local --server=https://$2:6443 --certificate-authority=$PWD/$1-cluster-ca.crt

kubectl config set-context $1-kubernetes-admin@$1-clster.local --cluster=$1-cluster.local --user=$1-kubernetes-admin --namespace=default --current=false

kubectl config set-credentials $1-kubernetes-admin --client-certificate=$PWD/$1-cluster-client.crt --client-key=$PWD/$1-cluster-client.key

echo "###kubectl config get-contexts###"
kubectl config get-contexts

------------------------------------------------------------

1.개요

- K8S에는 Pod Security Policy(PSP)라는 기능이 있어서 클러스터에 정책을 설정할 수 있음

- Open Policy Agent(OPA) 라는 솔루션은 K8S 뿐 아니라 범용적으로 정책을 만들어 적용할 수 있음

- OPA에서는 K8S 클러스터에 정책을 적용 할 수 있는 Gatekeeper라는 전용 솔루션을 제공

- PSP는 K8S 1.25 버전부터 지원 종료가 예정되어있으며, 그 이후부터는 OPA(Gatekeeper)를 사용해야 함 

2. Open Policy Agent

- OPA는 플랫폼 관리자에게 세밀한 권한 관리를 할 수 있도록 지원하는 범용 정책 엔진으로 K8S 뿐 아니라 OPA 엔진을 이용하는 모든 플랫폼에서 사용 가능

(1) OPA 동작

• 요청이 들어오면 서비스는 JSON을 이용하여 OPA에 허용 여부 질의

• 질의를 받은 OPA는 저장된 Policy를 불러와서 요청에 대한 평가를 하고 결과를 다시 JSON 형식으로 서비스에 반환

(2) 정책 설정

• OPA는 Policy를 기반으로하여 사용자 접근을 관리하기 때문에 Policy를 어떻게 작성하는지가 중요함

• Policy는 Rego라는 자체 질의언어를 이용하여 작성해야 하며, Rego 언어가 선언적으로 동작하기 때문에 해당 문법에 대한 이해 필요

3. 게이트키퍼

- 게이트키퍼는 내부적으로 OPA 엔진을 사용하는 OPA의 K8S 승인/제어를 위해 제작된 솔루션

(1) 게이트키퍼 동작

• K8S에서는 정책적인 결정을 API 서버와 분리하여 독립적으로 할 수 있게 Admission Controller Webhook (이하 웹훅) 제공

• 웹훅은 클러스터가 변경될 때 무조건 실행되며, 게이트키퍼는 웹훅을 확인하여 OPA 정책 엔진에서 정의한 대로 실행

(2) 주요기능

• Validating Admission Control

  - 웹훅을 트릭거로 OPA와 api-server 다리 역할을 하여 정책 적용

• Policies and Constraints

  - Rego 언어로 작성되며 정의한 요구하상을 위반하는 리소스들을 확인

• Audit

  - 배포된 자원을 정기적으로 감사하여 Constraints에 반하는 것이 있는지 확인

• Data Replication

  - 리소스를 복제 한 후 감사가 진행되며, 복제할 수 있도록 권한 부여 필요

4. 게이트리퍼 라이브러리

- K8S에서 일반적으로 사용하는 정책에 대한 샘플 제공

* https://github.com/open-policy-agent/gatekeeper-library

PSP에 해당하는 기능을 게이트키퍼 탬플릿으로도 제공 함

5. 게이트키퍼 라이브러리 샘플

(1) 구조

 - OPA 정책에 대한 탬플릿 파일과 제약사항 정의파일 및 예제파일로 구성

(2) 테스트

 - template.yml 적용

 - constraint.yaml에 본인 repository만 허용하도록 적용

 - 허용되지 않은 repository image를 사용해서 pod 생성