쿠버네티스 공부하기 3 - yaml 파일을 활용한 deploy/service 하기

https://loy124.tistory.com/402

쿠버네티스 공부하기 2 - 간단하게 deploy/service 하기

이전 시간에는 커맨드를 활용한 deploy/service를 진행해 보았다. 

 

이제 해당 커맨드 -> 파일을 활용해 현재 어떤 상태인지 파일로 관리하게 하겠다.

 

이제 yaml 파일을 작성하고 해당 yaml을 쿠버네티스에서 읽어서 활용해 보는 시간을 가지겠다. 

 

 

만약에 이전 글에서 실습한 내용이 남아있다면 

kubectl delete service nginx

kubectl delete deployment nginx

명령어를 통해 존재하는 service와 deployment를 지워주도록 한다. 

 

이제 먼저 Deployment에 대한  yaml 파일을 을 작성해 보도록한다.

 

Deployment yaml 파일 만들기 

 

nginx-deployment.yaml

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  # namespace: my-namespace   # 네임스페이스 지정 kubectl create namespace my-namespace로 미리 생성해두어야 동작한다.
  labels:
    app: nginx
    version: v1
  annotations:              # 주석(annotations) 추가
    description: "Nginx Web Server Deployment"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
      version: v1           
  template:
    metadata:
      labels:
        app: nginx
        version: v1        
      annotations:         
        author: "onyou"
    spec:
      containers:
        - name: nginx-container
          image: nginx:latest
          ports:
            - containerPort: 80

 

apiVersion

스크립트를 실행하기 위한 쿠버네티스의 API 버전을 의미한다.

쿠버네티스에서는 API 서버를 통해 메시지를 주고 받는데 이에 따라 버전 명시를 명확하게 할 필요가 있다.

 

kind

리소스에 대한 종류를 명시한다.

ex0 kind가 Deployment라면 해당 yaml이 Deployment임을,
kind가 Service 라면 해당 yaml 파일이 Service라고 알려주는 역활을 하고있다.

 

metadata

• name  - 리소스의 이름을 나타낸다. 고유한 이름으로 작성해야한다. 
• namespace - 리소스가 속하는 네임스페이스를 나타낸다. 명시하지 않을경우 default namespace로 생성된다.
• labels - 리소스에 레이블을 부여해서 키-값 으로 리소스를 구분할때 사용한다. 
• annotations - 리소스에 대한 추가적인 메타데이터를 기술할때 사용한다. 

 

 

spec

리소스 생성을 위해 자세한 정보를 명시한다. (어떤 컨테이너를 사용하고, 어떤 이미지를 사용할것인지, 어떤 포트를 사용할것이지 등)

 

쿠버네티스의 현재 status 를 -> spec에 맞게 변경시킨다. 

 

  selector:
    matchLabels:
      app: nginx
      version: v1           
  template:
    metadata:
      labels:
        app: nginx
        version: v1

selector  

deployment가 관리하는 파드를 선택하기 위한 레이블 셀렉터  app이 nginx이고 version이 v1 인 파드를 선택하게 되어있다.

 

template

deployment가 새로운 파드를 생성할때 사용할 파드 템플릿을 정의한다. 어떤 컨테이너가 실행되어야하는지 요구사항은

어떤지 지정할수 있다. 즉 template에 정의된 내용을 selector가 사용한다고 보면 된다. 

 

 

 

파일로 deployment 생성 하기 

파일로 deployment를 생성할 경우 앞으로 apply 라는 명령어를 활용할 예정이다.

 

이전 시간에는 create로 만들었던거 같은데? apply를 쓰는 이유가 있다. 

명령어 이름	차이점
create	리소스가 생성된 경우 수정이 불가능하다.
apply	리소스가 생성된 경우에도 spec에 맞춰 변경시킨다.

그럼 이제 apply로 한번 deployment를 만들어보고 해당 deployment를 수정해서 확인 또한 해보겠다.

 

apply -f   -f 옵션을 줘서 파일을 읽어서 생성할수 있다. 

 

kubectl apply -f nginx-deployment.yaml

kubectl get deployment

kubectl get pod

서비스가 성공적으로 생성된것을 확인할 수 있다.

 

describe 명령어를 활용하면 더 자세히 내역을 알수 있다. 

kubectl describe -f nginx-deployment.yaml

 

 

파일을 읽어서 deployment를 생성해 보았다. 

 

이제 nginx-deployment의 내용을 살짝 수정해 보겠다. 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  # namespace: my-namespace   # 네임스페이스 지정 kubectl create namespace my-namespace로 미리 생성해두어야 동작한다.
  labels:
    app: nginx
    version: v1
  annotations:              # 주석(annotations) 추가
    description: "Nginx Web Server Deployment"
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
      version: v1           
  template:
    metadata:
      labels:
        app: nginx
        version: v1        
      annotations:         
        author: "onyou"
    spec:
      containers:
        - name: nginx-container
          image: nginx:latest
          ports:
            - containerPort: 80

 

pod의 갯수를 담당하는 replicas를 3 -> 2로 변경하였다. 

 

이제 다시 실행해보자. 

kubectl apply -f nginx-deployment.yaml

kubectl get deployment

kubectl get pod

 

 

pod가 3개에서 2개로 줄어든것을 확인할 수 있다.

 

이렇게 apply  + yaml 파일의 조합을 활용하면 spec을 변화시켜 적용하는것이 굉장히 편리해진다. 

 

 

이제 서비스에 대한 yaml 파일을 만들어볼 차례이다. 

Service yaml 파일 만들기 

 

 

nginx-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx        # 해당 레이블을 가진 파드들을 선택
  ports:
    - protocol: TCP
      port: 80        # 서비스가 노출하는 포트
      targetPort: 80  # 파드의 컨테이너 포트

 

이제 만든 yaml로 service를 실행시켜 보겠다

 

방식은 똑같이 apply -f 로 파일을 읽어서 실행시키면 된다.

kubectl apply -f nginx-service.yaml

kubectl get serivce -o wide

minikube service nginx-service

 

 

 

여기까지 쿠버네티스에서 파일을 활용해 Deployment, Service를 배포하는 법을 알아보았다. 

 

 

 

+

 

Kind 및 ApiVersion 명시 알아 보는 법 

yaml 파일 작성시에 ApiVersion은 어떻게 작성해야하는지, Kind는 어떻게 작성해야하는지 혼동이 오는 경우가 있다.

이럴땐 해당 명령어로 쉽게 찾는게 가능하다. 

kubectl api-resources

위 명령어로 조회할수 있다. 

 

쿠버네티스 버전 명시 

NAME	SHORTNAMES	API VERSION	NAMESPACED	KIND
bindings		v1	true	Binding
componentstatuses	cs	v1	false	ComponentStatus
configmaps	cm	v1	true	ConfigMap
endpoints	ep	v1	true	Endpoints
events	ev	v1	true	Event
limitranges	limits	v1	true	LimitRange
namespaces	ns	v1	false	Namespace
nodes	no	v1	false	Node
persistentvolumeclaims	pvc	v1	true	PersistentVolumeClaim
persistentvolumes	pv	v1	false	PersistentVolume
pods	po	v1	true	Pod
podtemplates		v1	true	PodTemplate
replicationcontrollers	rc	v1	true	ReplicationController
resourcequotas	quota	v1	true	ResourceQuota
secrets		v1	true	Secret
serviceaccounts	sa	v1	true	ServiceAccount
services	svc	v1	true	Service
mutatingwebhookconfigurations		admissionregistration.k8s.io/v1	false	MutatingWebhookConfiguration
validatingwebhookconfigurations		admissionregistration.k8s.io/v1	false	ValidatingWebhookConfiguration
customresourcedefinitions	crd,crds	apiextensions.k8s.io/v1	false	CustomResourceDefinition
apiservices		apiregistration.k8s.io/v1	false	APIService
controllerrevisions		apps/v1	true	ControllerRevision
daemonsets	ds	apps/v1	true	DaemonSet
deployments	deploy	apps/v1	true	Deployment
replicasets	rs	apps/v1	true	ReplicaSet
statefulsets	sts	apps/v1	true	StatefulSet
tokenreviews		authentication.k8s.io/v1	false	TokenReview
localsubjectaccessreviews		authorization.k8s.io/v1	true	LocalSubjectAccessReview
selfsubjectaccessreviews		authorization.k8s.io/v1	false	SelfSubjectAccessReview
selfsubjectrulesreviews		authorization.k8s.io/v1	false	SelfSubjectRulesReview
subjectaccessreviews		authorization.k8s.io/v1	false	SubjectAccessReview
horizontalpodautoscalers	hpa	autoscaling/v2	true	HorizontalPodAutoscaler
cronjobs	cj	batch/v1	true	CronJob
jobs		batch/v1	true	Job
certificatesigningrequests	csr	certificates.k8s.io/v1	false	CertificateSigningRequest
leases		coordination.k8s.io/v1	true	Lease
endpointslices		discovery.k8s.io/v1	true	EndpointSlice
events	ev	events.k8s.io/v1	true	Event
flowschemas		flowcontrol.apiserver.k8s.io/v1beta3	false	FlowSchema
prioritylevelconfigurations		flowcontrol.apiserver.k8s.io/v1beta3	false	PriorityLevelConfiguration
ingressclasses		networking.k8s.io/v1	false	IngressClass
ingresses	ing	networking.k8s.io/v1	true	Ingress
networkpolicies	netpol	networking.k8s.io/v1	true	NetworkPolicy
runtimeclasses		node.k8s.io/v1	false	RuntimeClass
poddisruptionbudgets	pdb	policy/v1	true	PodDisruptionBudget
clusterrolebindings		rbac.authorization.k8s.io/v1	false	ClusterRoleBinding
clusterroles		rbac.authorization.k8s.io/v1	false	ClusterRole
rolebindings		rbac.authorization.k8s.io/v1	true	RoleBinding
roles		rbac.authorization.k8s.io/v1	true	Role
priorityclasses	pc	scheduling.k8s.io/v1	false	PriorityClass
csidrivers		storage.k8s.io/v1	false	CSIDriver
csinodes		storage.k8s.io/v1	false	CSINode
csistoragecapacities		storage.k8s.io/v1	true	CSIStorageCapacity
storageclasses	sc	storage.k8s.io/v1	false	StorageClass
volumeattachments		storage.k8s.io/v1	false	VolumeAttachment

(명령어를 가져와서 표를 만들어봤다.)