정보보안 스터디 - 11주차 2일 - kubernetes 파드 종류, 서비스

☞ 파드 종류

 

init 컨테이너 파드

initContainers: name: init-myservice name: init--mydb

메인 컨테이너를 작동시키기 전에 미리 테스트로 동작시킬 컨테이너입니다.

until ~ do ~ done 이 실행되고 종료되었다면 메인 컨테이너를 실행합니다.

 

인프라 컨테이너 파드는

파드의 환경을 만들어주는 컨테이너 입니다.

 ip주소, 호스트이름 등을 관리 합니다.

 

static 파드

cat /var/lib/kubelet/config.yaml > /etc/kubernetes/manifests 설정디렉토리에

test.yml 파일을 생성하기만해도 실행이됩니다.

 

 

파드 설정 가능한 옵션

initservice

리소스 cpu, 메모리 제한할 수 있습니다. lscpu lsmem request 최소 이정도는 해야된다는 제한 limit 최대 제한을 설정합니다. cpu = 1(m:밀리코어) 1mi = 1024 ki 예를 들어 실제 리눅스가 cpu 4코어 밖에 없는데 그 이상인 6을 요청하면 실행을 못합니다.

라이프사이클 설정 가능 : 몇번 실패하면 fail, 주기 설정

환경변수 설정이 가능합니다.

 

 

 

 

☞ 컨트롤러 

컨트롤러는 클러스터/파드 상태를 감시하고 관리하는 일을 합니다.

컨트롤러는 여러가지 다양한 종류가 있으며 상황에 따라 사용하면 됩니다.

하지만 기본적으로 많이 쓰는건 deployment입니다.

 

kubectl api-resources 에서 보면 api 기능들이 쭉 뜹니다.

버전과 컨트롤러 종류와 이름이 뜹니다.

 

 

 

레플리케이션 컨트롤러

kind: Replicationcontroller

apiversion: v1 

replicas는 pod을 복제해줍니다.

replicas를 3으로 해놓는다면 고정된 갯수인 3에 맞춰서 pods가 삭제돼도 생성이됩니다.

노드에 파드를 스케줄러가 적절하게 배치하지만 노드에 한쪽으로 몰아놓지는 않을거니까 노드 당 하나씩 배치할 것입니다. 노드에 장애가 생기면 남는 다른 노드에 넣어서라도 3개의 파드를 유지합니다. 

replicas=3

 

 

app: main selector:  matchLabels:       app:main template:   metadata:      name:      labels:        app:main

app은 그룹이름입니다.

레이블은 이름표같은 것이며

selector : matchLabel로 레이블을 검색하고 연결하여- templates이 부족한 장애가 생기면 부족하네 하고 추가합니다.

 

replicas변경

kubectl scale rc my-rc --replicas=4

 

kubectl get pods,deploy,rs -o wide 상세확인

 

 

 

레플리카셋 replicationsets

apiversion: apps/v1

rs는 replication controller와 비슷한 개념이지만

일정한 조건이 됐을 때 필요한 레이블을 선택할 수 있습니다.

삭제를 하려면 rs전체를 지워야합니다.

 

 

deployments

가장 기본이 되게 많이 쓰는 종류입니다.

apiversion: apps/v1

rs를 품고있기 때문에 rs를 지워도 다시 생성됩니다.

같은개념이지만 실행 중간에 업데이트 등 버전 변경이 가능하며

다시 롤백을 할 수 있는 장점이 있습니다.

--record 는 해줘야 롤백이 가능합니다.

 

 

 

 

 

 

 

업데이트 하는방법은 3가지로 나뉩니다.

set image

일단 create부터하고

kubectl create -f test.yml > httpd:2.2

 

 

kubectl set image deployment deploy-test httpd-container=httpd:2.4 --record

kubectl rollout history deployment deploy-test

kubectl rollout undo deploy deploy-test [--to-revision=2] 2번 전으로 건너띕니다.

 

edit 

kubectl edit deploy deploy-test

image: httpd:2.2 > 2.4 변경

바로 적용 되는 것을 볼 수 있습니다.

 

vi

vi edit.yml

image: httpd:2.2 > 2.4 변경

지우지말고 create가 아닌

kubectl apply -f deploy.yml 로 적용 가능합니다.

 

 

 

daemonset = ds

replicas 를 설정안해도

노드에 무조건 하나의 파드를 가지게 보장 하는 컨트롤러입니다.

노드를 하나지우고

다시 노드에서 직접 조인해서 추가 했을 때 바로 파드가 추가되는 것을 볼 수 있습니다.

 

 

 

statefulsets

마찬가지로 파드 생성하지만 

파드의 상태를 고정시켜줍니다. (파드 이름, 볼륨 등)

파드 이름이 원래는 컨트롤러이름옆에 랜덤으로 떴었지만

1 2 3 으로 고정이 되며 삭제되고 난뒤에도 변함없습니다.

 

원래 파드가순서대로 추가가 됐다면

parallel로 변경하면 한번에 생성시킵니다.

 

 

jobs 컨트롤러

jobs 한번만 정해진 시간에 칼같이 지킵니다. 리눅스에서 at과 같은 역할을 합니다.

cronjobs 주기적으로 반복하기에 좋습니다. 리눅스에서 cron과 같은 역할을 합니다.

 

반복은

분 시 일 달 요일로 됩니다.

 

30 5 1 * * 이라면

매달 1일 오전 5시30분마다 반복입니다.

만약 "* * * * *" 이라면  1분마다 반복하겠다는 뜻이됩니다.

실제로 확인하면 1분마다 파드(템플릿)를 생성하고 명령어가 실행되서 만들어지는 모습을 볼 수 있습니다.

하지만 replicas를 3개로 제한했기 때문에 더이상 생성안되고 로그에 보면 명령어는 계속 반복합니다. 

 

 Forbid 로 설정했기 때문에 명령어 실행이 다 되고 나서 다시 반복합니다.

allow로 할 경우 명령어 실행과 상관없이 시간이 되면 스케줄러 반복합니다.

 

한번 실행이 완료됐다면 completed로 뜨고

로그를 확인하면 명령어위주로 확인가능합니다.

kubectl logs jobs/jobs-test1 centos-container

 

 

 

테스트가 끝났다면 삭제해줍니다. 

kubectl delete deployment --all kubectl get all kubectl get all -A | grep  pods 말고 네트워크 관련 해서도 볼 수 있습니다

 

 

 

 

 

☞ 네트워크 역할을 하는 service

기본값은 cluseterIP 이기 때문에 굳이 적지 않아도 네트워크 내역에서 생성이 됩니다.

확인해보면 네트워크는 서브넷 마스크 192.168.0.0 부터 /18 대인

범위내에서 할당됩니다.

 

clusterip 각각의 파드에 하나의 ip가 전달되기 때문에. 컨테이너의 페이지를 다르게했을 때는 curl을 했을 때 번갈아서 접속이 되는 것을 확인할 수 있습니다. 고정된 ip를 쓰려면 clusterIP: 192.168.10.10 으로 설정해주면됩니다.

nodeport 모든 노드에 ip를 따로 적용시킵니다.  기본 포트가 30000~32767 번입니다. IP:30200 로 접속합니다.

loadbalancer  분산처리합니다.

external 안에서 외부로 접속시 사용합니다.

 

 

서비스는 파드 생성과 따로이기 때문에

각각 yml파일로 생성해주거나

---으로 분리해서 한번에 생성가능합니다.

 

서비스를 만들게 되면 정보확인에서 확인은 물론이고 리눅스의 ip가 하나더 생깁니다.

kubectl describe svc

ip addr