CKA Study Day4

김건호·2023년 3월 30일

36-48

Cluster IP

fe be db 각각 연결을 하고 싶어함

파드 모두 할당된 IP 있음 -> 정적이 아님
파드 하나로 묶고 싱글 인터페이스 단체 파드에 접근 가능

각각의 서비스는 클러스터 내부에 ip와 이름이 있음
다른 파드가 서비스에 접근 시 이 이름과 IP로 사용

apiVersion: v1
kind: Service
metadata:
  name: back-end

spec:
  type: ClusterIP
  port:
    - targetPort: 80
      port:80
  selector:
    app: myapp
    typeL back-end

Loadbalancer (Service)

노드포트는 외부에서 노드로 접근할 수 있도록 함
파드는 노드의 호스트 되어있음 -> 노드 클러스터가 있음

싱글 URL이 필요 함 ex) http://example-vote.com
로드밸런서 설치 -> 트래픽 분산
GCP, AWS, 네이티브 로드밸런서 사용 가능 -> 쿠버네티스에서 통합 지원

apiVersion: v1
kind: Service
metadata:
  name: back-end

spec:
  type: LoadBalancer
  port:
    - targetPort: 80
      port:80
  selector:
    app: myapp
    typeL back-end

NameSpace

리소스 생성은 ns안에서 이루어졌음 -> defalut ns
쿠버네티스 생성시 기본적으로 생성

스태틱 파드들은 kube-system ns에 저장됨 -> 삭제 방지
kube-public ns 모든 사용자가 사용할 수 있는 리소스 생성 됨

연습용은 default 사용가능, 프로덕션 환경 ns 사용 고려해야함
개발과 생산환경 클러스터는 같지만 리소스 분리

ns 각각 고유한 정책 부여 가능 -> 리소스 할당도 가능

ns도 간단히 이름으로만 부를 수 있음 -> ex) mysql.connect("db-service")
다른 ns도 접근 가능 mysql.connect("dbservice.dev.svc.cluster.local")
서비스가 생성될때 dns 항목이 자동으로 이 포맷에 추가가 됨
마지막이 cluster.local 쿠버네티스 클러스터 도메인
svc 서비스 dev ns dbsevice 서비스 이름

k get pod -> default
k get pod -napmspace
k get pod -n kube-system

k create -f pod.yaml -n dev
metadata 아래에 namespace 지정 가능

apiVersion: v1
kind: Namespace
metadata:
  name:dev

k create ns(namespace) dev

네임스페이스 전환
kubectl config set-context $(kubectl config current-context) --namespace=dev
현재 네임스페이스 식별 후, 원하는 네임스페이스 선택
모든 네임스페이스
get pod --all-namespaces

리소스 할당

apiVersion: v1
kind: Namespace
metadata:
 name:dev
 
spec:
 hard:
   pods: "10"
   requests.cpu: "4"
   requests.memor: 5Gi
   limits.cpu: "10"
   limits.memeory: 10Gi

Imperative vs Declarative

IaC 인프라 접근법이 다양함

Imperative 단계적
Declarative 최종 목적지 설정하면 알아서 도착

Imperative vm 생성 - 앱 설치 - 수정

Declarative 웹서버가 필요해! 라고 선언만 함
-> 설명할 필요가 없음
ex ) terraform, Chep, ansible, 퍼펫

업데이트가 쉬움 선언만 하면 시스템이 알아서 수정사항만 적용

kubectl run - image=nginx nginx 와 같이 사용

kubectl set image deploy nginx nginx=nginx:1.18

개체를 생성 수정 삭제 함으로 요구에 맞게 인프라를 관리

kubectl apply 어떤 변화가 있는지 확인후 변화한 내용만 적용

명령 한번 실행하면 잊혀짐 -> 히스토리에만 확인 가능
-> 구성파일로 관리해야함

kubectl edit deploy nginx -> kubernetes memory에 있는 파일을 불러옴 -> 개체 생성시 사용한 파일이 아님
라이브 개체가 변화하지만 원래 파일은 변화하지 않음

개체 완전히 삭제 및 재생성 --> --force 옵션 적용
--> Imperative

이미 존재한다면 create 실패 -> 개체가 먼저 존재하는지 확인
없으면 replace -> 실패

kubectl apply -f -> Declarative
kubectl apply -f 디렉토리 -> 디렉토리내에 모든 파일 생성

시험 팁

kubectl run --image=nginx nginx
kubectl create deploy --image=nginx nginx
k expose deploy nginx --port 80 <- service 생성 명령어
k edit deploy nginx
k scale deploy nginx --replicas=5
k set image deploy nginx nginx=nginx:1.18

수정시 edit 명령어

쿠버네티스 문서 익숙해지기!