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; }
