1. Object
p. 112
기본 Object
- 기본 오브젝트는 파드, 네임스페이스, 볼륨, 서비스 이다
- 파드 : K8S 의 최소 실행 단위
- 네임스페이스 : 클러스터에서 사용하는 자원들을 구분해서 관리하는 그룹. 사용자 별로 작업 공간을 제공해준다. 네임스페이스 오브젝트는 Pod 의 네임스페이스와 다르다
- 볼륨 : 파드에서 사용할 수 있는 디렉터리를 제공하며, 파드는 영속되지 않으므로, 파드는 해당 디렉터리를 임시로 사용한다. 따라서, 파드가 사라지더라도, Data 는 저장 및 보존이 가능하다
- 서비스 : 파드는 클러스터 내에서 유동적이기에 접속 정보가 고정이 아니므로, 이 파드 접속을 안정적으로 유지하도록 서비스를 통해 내부 / 외부로 연결한다
OBJECT 에서 말하는 서비스는 웹 서비스 같은게 아니라 포드를 외부로 노출시키고, 외부에서 연결이 가능하도록 하기 위한 OBJECT 로서 다음의 3 가지를 이용한다
- CLUSTER IP : NODE ( 가상 머신 ) 밖으로 노출은 안된다
- NODE PORT : 서비스의 특정 포트와 포드를 연결하여 외부로 부터 연결 가능
- LOAD BALANCER : 로드 밸런서를 이용하여 포드와 연결 ( L4 )
위 3 가지는 L7 이 아니며, L7 LB 와 같은 기능은 ingress OBJECT 에서 제공
Pod 나 Deployment 와 같은 요소들은 Object 이다. 이를 배포하는 것은 Object 를 배포하는 것이다. 만약, Pod 를 배포한다고 하면, Pod Object 에게 명령을 내려서, 사용자 설정을 추가한 Pod Object 를 복사 및 생성하여 배포해주는 것이다
이외의 Object - Deployment & ReplicaSet
Deployment
- 기본 오브젝트 만으로도 K8S 를 사용할 수 있지만, 한계가 있으므로, 효율적인 작동을 위해 기능들을 조합하여 추가해 구현한 것이 Deployment 이다. 이외에도 데몬셋, 컨피그맵, PV 등이 있다
ReplicaSet
p. 117
-
ReplicaSet 은 Container 가 아닌 고정된 수의 Pod 를 유지하는 것이다. ReplicaSet 을 통해 효율적으로 다수의 Pod 를 제공한다. ReplicaSet 은 Pod Object 를 포함한다
- 이때 레플리카셋에서는 label 의 개수를 통해 Pod 의 개수를 확인한다
-
이 ReplicaSet 의 상위 개념이 Deployment 이다. Deployment 에서는 Rolling Update 도 가능하며, ReplicaSet 을 포함한다. 따라서, Pod 의 개수를 유지하며, Rolling Update 가 가능하다
- 위와 같이 ReplicaSet 을 정의한다. 위에 template 부분 전까지가 ReplicaSet 정의이고, 밑에가 Pod 에 대한 정의이다
- Pod 에 label 을 지정하고, ReplicaSet 에서 label 을 통해 Pod 개수를 유지한다
2. ReplicaSet 배포
ReplicaSet 배포 및 확인
- 위와 같이 yml 파일을 작성하자
- 배포 후 ReplicaSet 과 Pod 의 정보를 확인하자. 3 개의 Pod 와 한 개의 ReplicaSet 이 생성되었다. 이 Pod 들의 이름은 모두 동일하면 안되므로, ID 값을 뒤에 붙여서 이름이 지정된다
- 각기 다른 Node 에 배포되었으며, Ip 역시 다르다
Pod 의 label 확인
- --show-labels 를 통해 Pod 의 label 을 확인 가능하다. 우리가 지정한 label 이 잘 설정되었다
ReplicaSet 동작 확인
- Pod 를 하나 삭제하여도, Pod 가 새로 생성되어 개수를 유지한다
- ReplicaSet 은 label 을 통해 개수를 유지하게 설정하였다
Pod 내용 편집 - labels 제거
- edit 를 통해 Pod 내용을 편집할 수 있다
- labels 부분을 주석 처리해주자
- 다시 Pod 를 확인해보면, Pod 가 4 개가 되었다. 이는 ReplicaSet 은 Pod 의 개수가 아닌 label 을 확인하기에, label 이 지워진 Pod 는 따로 동작하고, label 을 가진 Pod 가 새로 생성되었다
- 해당 yml 파일을 통해 삭제를 하면, 해당 파일의 내용을 가진 Pod 만 삭제되기에 label 을 가진 Pod 만 삭제된다. 즉, label 을 삭제한 Pod 는 삭제되지 않는다
3. Deployment 배포 및 Update
Deployment 는 ReplicaSet 을 포함하고, ReplicaSet 은 Pod 를 포함한다. 따라서 Deployment 객체를 배포하면, ReplicaSet 과 Pod 가 같이 배포된다
Deployment 배포 및 확인
Deployment 는 버전 관리가 가능하다
- Deployment 는 ReplicaSet 의 상위 개념인 만큼 ReplicaSet 과 유사하다
- 위와 같이 작성해주자
- 생성된 것을 확인하자. Deployment, ReplicaSet, Pod 가 모두 배포되었다
- ReplicaSet 가 관리하는 label 을 확인하면, 우리가 지정한 label 과 처음 보는 label 이 있다. 이때, 이 label 은 ReplicaSet 의 label 이 아니라, ReplicaSet 이 관리하는 Pod 의 label 이다
- Deployment 를 이용하여 Update 를 하면, 하위에 있는 ReplicaSet 이 생성된다. 우리는 두 ReplicaSet 의 정보를 확인해서 둘 다 동일한 지정 label 이 있다는 것을 확인할 수 있다. 만약, ReplicaSet 의 개수를 늘린다면, 신규 이미지를 활용한 Pod 만 추가되야 한다. 이때, 지정 label 만 있다면, 예전 버전의 Pod 들도 늘어날 것이다. 이를 방지하기 위해 Deployment 에서 각 ReplicaSet 을 구분해야 하므로, 자동으로 label 이 생성되어 추가된다
- 따라서, Deploment 는 label 을 두 개 확인해서, 해당 label 에 맞는 Pod 를 관리해준다
- 결론, Deployment 는 이미지의 버전 관리가 가능하여 기존 버전에서 생성된 Pod 들과 신규 이미지에서 생성된 Pod 를 구분하기 위하여 추가적인 label 을 자동으로 생성한 뒤, 이를 Pod 에 붙여준다. 이를 통해 기존 Pod 와 신규 Pod 를 구분할 수 있다
이때, Deployment 는 Pod 의 label 을 본다. 따라서, Deployment 는 Pod 의 버전을 관리하는 것이다
Rolling Update
- Image 를 httpd 로 바꿔서 Update 해주자. 이는 컨테이너 이름 = 이미지 이름 을 통해 해당 컨테이너의 Image 를 바꾸어 Update 해주는 것이다
- Pod 에 접속하면, httpd 임을 알 수 있다
history 확인
- history 를 보면 Update 기록을 확인 가능하다. 우리는 현재 revision 4 에 있다
Roll Back
- 위와 같이 revision 을 지정하여 돌아갈 수 있다. 1 이니까 초기 버전으로 돌아가는 것이다
- replica 정보를 확인하면, 과거에 생성된 replica 로 돌아온 것을 확인할 수 있다
- Deployment 에서는 버전 관리를 위해서 label 을 자동 생성하여 추가한다. 이를 통해 Update 및 Roll Back 시 label 을 통해 Pod 를 구분하여 동작한다
- roll back 시, 기존에 중지된 과거 버전의 ReplicaSet 이 다시 동작하며, 최신 버전의 ReplicaSet 은 중지한다
버전 관리를 위해서는 파일 수정을 하지말고, 위와 같이 명령어로 버전 관리 해야한다
- 모두 삭제시키자
4. Service 사용하여 외부 연결하기
우리는 Service 를 배포하여 외부에서 해당 LB 에 접근하면, 각 NODE 들에 요청을 전달하게 해볼 것이다
- 이때, selector 에서 label 을 통해 해당 label 의 Pod 에만 요청을 보내게 할 수 있다
- externalTrafficPolicy 는 외부에 있는 사용자가 LB 에 접근할 때, LB 는 라운드 로빈 방식으로 전달해준다. 이때, 라운드 로빈할 범위를 지정해주는 것으로, local 로 설정하면, local 에서만 동작하게 한다. 만약 local 로 지정했을 때, 해당 Node 에 접속 가능한 Pod 가 없다면, 다른 Node 로 보내지 않는다. 범위가 local 이기에 해당 Node 에서만 요청을 돌리게 한다
Service 는 Type 마다 접근 방식이 달라진다. LB 는 엔드포인트 Ip 를 통해 접근 가능하지만, nodeport 는 Node 의 Ip 를 알아야한다. 이는 nodeport 는 Node 안에 존재하므로, Node 의 Ip 와 지정한 Port 번호를 통해 Service 에 접근하면, Service 가 연결된 Port 에 따라 Pod 에 요청을 보내주는 방식이다
Service.yml 작성 및 확인
- 위와 같이 작성한다. 타입이 Loadbalancer 이므로, select 의 label 에 맞는 Pod 들에 라운드 로빈 해준다. 이때, Service 의 포트는 80 이며, Pod 의 포트 ( targetPort ) 는 80 으로 지정하여 연결하였다
- 만들어졌다
- Pod 를 배포하자
- 잘 접속된다
Update 및 Rollback 확인
- httpd 로 바꾸어 Update 하자
- 잘 적용됬다
- Rollback 시키자
- 다시 변경되었다
이제 다 삭제하자
멋진 엔지니어가 될 때까지