1) Replica Set의 DESIRED 카운트가 1인 경우, Pod가 삭제되면 어떻게 되는가?
: Replica Set 컨트롤러에서 DESIRED 카운트가 1이기 때문에 pod가 삭제 되어도 다시 생성을 한다.
2) 컨트롤러가 없는 pod는 바로 지워진다.
3) 상위에 컨트롤러가 있는 pod의 경우 삭제가 안되므로, 상위객체를 삭제해 버린다.
4) 하위 리소스 자동제거 하지 않기 (--cascade 사용)
상위 deployments 컨트롤러만 삭제되고 하위 pod는 남아 있는 것을 확인
여기까지는 객체 단위로 삭제하는 방법
5) 배포 단위로 삭제하는 방법
1)kubectl delete -f sample demo.yaml : 등록한 yaml 파일 기반 삭제 2)kubectl delete ns test-ns : 네임스페이스 기반 삭제 3)Kubectl delete po | deploy | rs --all : 디폴트 네임스페이스의 po | deploy | rs 모두 삭제 4)helm remove release-name : k8s 어플리케이션을 helm을 이용하여 설치 가능 : 리소스 그룹을 release 라고 부른다.
Client -> Service -> [Load Balancer(L4 스위치 기능수행)] -> pod
하위 객체에 Lable을 달아서 상위객체(service)에서 Selector로 연결
DNS 또한 Pod 형태로 띄워져 있음
Service 객체를 만들면 DNS쪽에 객체가 생성
service의 yaml 명세서 확인
apiVersion: v1 kind: Service metadata: name: test-svc spec: ports: -port: 80 (서비스 포트 80) targetPort: 8080 (pod 안에 expose가 8080 포트 : Service 객체는 80으로 요청오면 8080으로 전달해 줌) selector: run:test
Endpoint Controller
서비스 객체를 만들면 LB 기능을 한다.
그러려면 pod 안에 컨테이너 포트/타겟 포트의 조합을 알아야 한다.
즉 엔드포인트 라는 하위 리소스가 자동으로 만들어 짐
Service Types
- 4가지의 서비스타입이 존재 1.ClusterIP
사설IP 내부통신만 가능
하나의 노드에 부하될 수 있는 문제점이 있음
2.NodePort
ClusterIP + HostPort 서비스 객체를 생성하면 내부적인 iptables 룰셋, DNS 룰셋 등등 [내부 - 외부]간 통신 가능하도록 설정. 누가? Kube-proxy가 한다.
외부에서 내부 pod를 접근하려면 HostPort가 필요
1,2는 온프레미스 환경에서 k8s 구축시 사용
서비스의 iptables를 바탕으로 End Point 를 갖고 노드에 분산시킴
인바운드 리퀘스트를 분산시킴
3.LoadBalancer
NodePort + LB 연동 추가
클라우드 환경에서 k8s 구축시 사용
4.ExternalName
CNAME 레코드
1, 2, 3은 외부 -> 내부pod 접근하기 위한 방법
4은 내부pod -> 외부 서비스를 접근하기 위한 방법
서비스 객체 생성하기
- kubectl expose deployment nginx --port=80 --target-port=8000 : deployment 의 service 객체 생성
1) --port=80 : 서비스 객체 포트 명시 2) --target-port=8000 : pod안의 Container 포트 명시
- 1번째로 ClustIP 타입의 svc 생성 후 확인
root@ip-172-31-4-27:~# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 5h2m root@ip-172-31-4-27:~# kubectl get ep NAME ENDPOINTS AGE kubernetes 172.31.4.27:6443 5h3m
1) pod IP : 172.31.4.27 2) api-server port : 6443
- 2번째로 NodePort 타입으로 Service 실행
root@ip-172-31-4-27:~# kubectl expose deployment hwk --port 80 --name web-hwk --type NodePort service/web-hwk exposed root@ip-172-31-4-27:~# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 5h16m web-hwk NodePort 10.107.229.55 <none> 80:32472/TCP 4s 해당 IP:PORT로 로 접근한다는 것은 SVC로 접근 한다는 뜻 root@ip-172-31-4-27:~# kubectl get ep NAME ENDPOINTS AGE kubernetes 172.31.4.27:6443 5h16m web-hwk 192.168.82.6:80 13s 해당 IP:PORT로 접근하는것은 pod로 직접 접근한다는 뜻 root@ip-172-31-4-27:~# kubectl get po hwk-66fdbfb65d-smrz5 -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hwk-66fdbfb65d-smrz5 1/1 Running 0 103m 192.168.82.6 ip-172-31-13-180 <none> <none>
- 실제 AWS EC2 public IP : 32472 로 접근이 가능하다. - 순서 : 1) 10.107.229.55:32472 요청 2) SVC는 -> 192.168.82.6:80 의 pod로 접근
- 상위 컨트롤러 -> 하위컨트롤러는 matchLabels를 갖고 연결 - template :
복제하기 위한 정보
RS에서는 DESIRED에 맞게 복제를 수행
이때 template 정보를 갖고 수행
그안에 containers 정보도 있음
pod의 lable 값을 확인 명령어
root@ip-172-31-4-27:~# kubectl get po nginx-6799fc88d8-v9m2z --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-6799fc88d8-v9m2z 1/1 Running 0 7m46s app=nginx,pod-template-hash=6799fc88d8
-o wide 옵션 주면 selector 정보 확인
root@ip-172-31-4-27:~# kubectl get rs nginx-6799fc88d8 -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR nginx-6799fc88d8 1 1 1 8m25s nginx nginx app=nginx,pod-template-hash=6799fc88d8
RS에서 pod를 컨텍하기 위해서 SELECTOR -> LABELS가 매치되어 있는것을 확인 할 수 있다.
root@master1:~# kubectl get event LAST SEEN TYPE REASON OBJECT MESSAGE 2m30s Normal Scheduled pod/mypod Successfully assigned default/mypod to ip-172-31-4-27 2m30s Normal Pulling pod/mypod Pulling image "nginx" 2m26s Normal Pulled pod/mypod Successfully pulled image "nginx" in 3.59835338s 2m26s Normal Created pod/mypod Created container hwk 2m26s Normal Started pod/mypod Started container hwk
Cluster 구성요소 (참조 : kubernetes in action)k8s 설치 이후 구성요소 확인
Deployment Controller 기반
Deployment 기반 배포란? - 가장 범용으로 사용 - Deployment 라는 상위 기반을 생성 - 하위 컨트롤러를 하나 더 소유 (Replica Set 컨트롤러) - Replica Set 은 Pod를 버전 별로 관리 - 예를 들어 Node에 문제가 발생한 경우, Pod를 재배포 하면 된다
절차 1. EC2 생성 2. IAM Role 생성 3. EC2에 IAM Role 연결 4. Cloudwatch-agent 설치 5. Cloudwatch-agent config.json 생성/설정 6. Cloudwatch-agent 시작 7. 로그그룹 생성 8. 로그스트림 생성 9. 로그 확인 10. SSM을 통한 Run command 수행
1. EC2 생성 후 IAM Role 연결
EC2 생성 후 IAM Role 연결/바꾸기 선택새 IAM 역할 생성 클릭
IAM Role 생성시 정책 두가지 연결 (CloudWatchAgentServerPolicy, AmazonSSMFullAccess)
- AS-IS : default 10회 - TO-BE : 8회 설정 예정 (사유 : default 설정인 경우 최대 51~60초에 delay 발생으로 response time이 길어지는 악순환이 되기 때문에 재시도 횟수를 줄여서 빠른 response 처리로 서버 부하 감소하기 위함)
예를 들어 첫 번째 재시도 전에는 최대 50밀리초, 두 번째 재시도 전에는 최대 100밀리초, 그리고 세 번째 전에는 최대 200밀리초를 기다리는 방식입니다. 하지만 1분 후에도 요청이 실패하면 요청량이 아니라 할당 처리량을 초과하는 요청 크기가 원인일 수도 있습니다. 따라서 약 1분 정도에서 멈추도록 최대 재시도 횟수를 설정하십시오.
[총 재시도 횟수 별 시간 참고]
[설정 방법]
/** * 처음 설정할 때 대기 시간 (밀리 초) * */ private static final int CONNECTION_TIMEOUT = 60 * 1000;
/** * 클라이언트가 실행을 완료 할 수있는 시간 (밀리 초) * */ private static final int CLIENT_EXECUTION_TIMEOUT = 60 * 1000;
/** * 요청이 완료되기까지 대기하는 시간 (밀리 초) * */ private static final int REQUEST_TIMEOUT = 60 * 1000;
/** * 데이터가 전송 될 때까지 기다리는 시간 (밀리 초) * */ private static final int SOCKET_TIMEOUT = 60 * 1000;
/** * 요청 실패시 재시도 카운트 * */ private static final int RETRY_COUNT = 8;
private AWSCredentialsProvider awsCredentialsProvider() { final BasicAWSCredentials awsCredentials = new BasicAWSCredentials(accessKey, secretKey); final AWSCredentialsProvider credentialsProvider = new AWSStaticCredentialsProvider(awsCredentials); return credentialsProvider; }
