17. Kube Scheduler
Kube Scheduler 에 대해 알아보자
remember the scheduler is only responsible for deciding which pod goes on which node. It doesn’t actually
place the pod on the nodes.
Scheduler은 어떤 pod를 어떤 nodes에 적재할지를 정한다. ( 결정만 하고 직접 포드를 노드에 옮기지 않는다. )
Pod를 만들고 어느 노드로 보낼지만 정한다 .
Scheduler는 적당한 컨테이너에 적재하도록 해야한다.
Pod를 최적의 노드에 분배할떄 원칙이 있다.
10 코어 pod를 노드에 실어야한다고 생각해보자
Filter 노드가 조건에 맞는 컨테이너만 남긴다. (3,4 번 남음)
Rank node는 적재를 했을 경우 자원이 많이 남는 것을 기준으로 컨테이너를 뽑는다.
(3번은 2개, 4번은 6개)
결국 4번 컨테이너를 고른다.
물론 우선 순위는 따로 지정할 수 있다.
scheduler에서 다뤄야할건 물론 많다.
Scheduler 설치하기
설치하기
기타 옵션 보기
18. Kubelet
큐블렛에 대해 알아보자
각 노드의 선장 역할
Scheduler 가 api를 통해 kublet에게 pod를 설치하라고 한다.
그럼 kublet은 engine( docker) 에게 pod 생성 명령을 내린다.
이후 kublet은 pod를 계속 감시하고 문제가 생기면 api 에게 보고한다 .
Kubeadm tool 을 쓰면 자동으로 kublet을 배포하지 않는다. 다른건 자동으로 하는데 kublet은 다르다 . 수동으로 worker노드에 설치해야한다.
Kublet 보기
19. Kube Proxy
Kube porxy 에 대해 배워보자
클러스터 내에 있는 모든 pod는 다른 pod와 통신할 수 있다.
Pod network 를 통해서 pod들은 통신한다.
첫째 node는 app을 운영하고 있고 둘쨰 node가 database를 맡는다고 가정하자.
Web app은 db의 ip를 통해서 접근할 수 있다.
하지만 ip가 바뀔 수도 있기 때문에 service를 만들어서 통신하는 것이 더 효율적이다.
Service도 network 를 통해서 pod 에 접근하는가 ? X
Service는 가상의 컴포넌트이다.
메모리 상에서만 존재 한다. ( no interface)
Kube-proxy is a process that runs on each node in the kubernetes cluster.
Kube proxy 는 새로운 service를 계속 탐색하고
Its job is to look for new services and every time a new service is created it creates the appropriate
rules on each node to forward traffic to those services to the backend pods.
Node에 대해 적절한 트래픽 규칙을 생성한다?
예를 들어 IP 테이블을 생성한다 .( 어떤 식인지는 정확히 모른다 .)
Installing
Proxy 확인하기
20 . Recap – PODS
가정
Application이 이미 개발되고 docker image에 설치 되었다고 가정한다.
또한 쿠버네티스 클러스터가 이미 셋팅되고 돌아가고 있다고 가정
This could be a single node setup or a multi node setup.
상관없음 .
서비스가 돌아가고 있다고 가정
쿠버네티스는 어플리케이션을 컨테이너에 올리는 것으로한다.
쿠버네티스는 직접적으로 컨테이너를 worker noder를 배포하지 않는다 .
The containers are encapsulated into a Kubernetes object known as pods.
A pod is a single instance of an application.
컨테이너는 pod 로 압축되고 각 node 에 실린다.
Pod는 쿠버 에서 만들수 있는 가장 작은 객체
가장 단순한 형태의 서비스가 있다고 치자
Node 안에 단일 pod 가 돌아간다.
만약 이용자를 추가하면
1번. Pod를 추가한다 .(pod안에 컨테이너를를 추가하지 않는다 .)
2번 node를 추가한다 .
Pod는 컨테이너와 주로 1대1 관계를 맺는다 .
보통 한 pod에 두개 이상의 컨테이너를 넣지 않지만 multi container pods에서는 …
똑같은 컨테이너를 넣기보다 다른 기능을 하는 helper container를 넣는다 .
container들은 또한 통신가능하다.
그냥 컨테이너 1과 helper 컨테이너를 무작위로 추가하면 나중에 컨테이너와 helper 컨테이너에 대한 mapping 정보가 있어야한다.
관리가 복잡해진다.
Pod를 통한 통합관리는 편하다 ( 수동으로 파드에 연결하기)
나중에 확장하기도 편하다.
kubectl run nginx 를 하게 되면
먼저 파드가 생성된다. 그리고 nginx 도커 이미지가 배포된다.
It first creates a pod automatically and deploys an instance of the engine x docker image.
설치할 때 application image에 대한 정보를 줘야한다.
Docker hub로부터 image를 다운받는다 .
Get pods 명령어로 pods 상태를 볼 수 있다.
지금 당장는 user가 Nginx webserver 에 접근할 수 없다.
차후 강의에서 알아본다 .
21. PODs with YAML
In this lecture, we will talk about creating a pod using a YAML based configuration file.
Yaml 파일을 쿠버네티스에 맞게 개발하는 법을 배워볼거다.
Kubernetes uses Yamal files as inputs for the creation of objects such as pods, replicas, deployments,
services, etc. All of these follow a similar structure.
Yaml 파일로 객체, 포드, 레플리카, 배포 등 다 할 수 있다.
A Kubernetes definition file always contains for top level fields the API version, kind, metadata
and spec.
루트 레벨의 속성이 있는데 먼저 api versrion에 대해 알아보자
apiVersion
우리가 사용하려는 쿠버네티스 api 버전이다.
Pod | v1
Service | v1
ReplocaSet | apps/v1
Deployment | apps/v1
kind
만들려는 객체 종류 ( 여기선 pod를 만들어보자)
Pod, service, replicaSet, deployment 들이 다 객체 종류들이다 .
Metadata
Name, labels 등등
딕셔너리 형태라는 점 .
작성할 때 위치 정렬해서 작성해야한다.
쿠버네티스에서 정해주는 속성들로 label을 사용해야하낟.
Spec
형태는 마찬가지로 딕셔너리 형태
사양을 기술한다.
컨테이너의 사양
아이템에 대한 기술은 ‘-‘로 시작한다.
Yaml 파일을 다 작성하면
Kubectl create -f pod-definition.yml
4가지 config 속성을 기억하라
Kubectl get pods 명령어로 돌아가는 pods를 확인한다.
Kubectl describe pod myapp-pod
으로 상세 확인
22. Demo - PODs with YAML
Yaml config 파일을 만들어보자
메모장으로도 가능함.
리눅스
Vim pod.yaml
Vi 에디터 열기
apiVesrion: v1
kind:Pod
metadata:
name: nginx
labels:
app: nginx
tier: frontend
spec:
containers:
- name: nginx
image: nginx
cat pod.yaml 로 파일 실행하기
kubectl apply -f pod.yaml
하면
pod/nginx created
라고 뜸
Kubectl get pods 로 상태확인
Kubectl describe pod nginx
로 상세확인하기
23. pratcie test introduction
시험 안내
24. Demo: Accessing Labs
Kodekloud 로 가서 시험처야한다.
26. Practice Test - Pods
1.How many pods exist on the system?
0개
2. Create a new pod with the nginx image.
잘 모를 때에는 kubectl run --help 를 통해서 찾아보자
3. How many pods are created now?
4개입니다!
4. What is the image used to create the new pods?
You must look at one of the new pods in detail to figure this out.
image 는 busybox 이다.
5. Which nodes are these pods placed on?
controlplane/172.25.1.76
위에서 확인 가능
6. How many containers are part of the pod webapp?
Note: We just created a new POD. Ignore the state of the POD for now.
들어가서 확인한다.
7. What images are used in the new webapp pod?
niginx 와 agentx 를 사용 8. What is the state of the container agentx in the pod webapp?
error or waiting
9. Why do you think the container agentx in pod webapp is in error?
ImagePullBackOff
도커 허브에서 이미지를 찾을 수 없음.
10. What does the READY column in the output of the kubectl get pods command indicate?
실행중인 컨테이너/ 전체 컨테이너 수
11. Delete the webapp Pod.
12. Create a new pod with the name redis and with the image redis123.
Use a pod-definition YAML file. And yes the image name is wrong!
yaml 파일 먼저 생성
create -f 로 강제 실행 시키기.
13. Now change the image on this pod to redis.
Once done, the pod should be in a running state.
vi 에디터로 이미지 이름 변경하고
kubectl apply -f redis.yaml 로 적용하면 된다.
28. Recap – ReplicaSets
Controllers are the brain behind Kubernetes.
They are the processes that monitor Kubernetes objects and respond accordingly.
Replica 와 replication controller의 역할
고가용성 High Availability
The replication controller helps us run multiple instances of a single part in the Kubernetes cluster,
thus providing high availability.
Pod 가 돌아가지 않는 상황을 대비해서 pod를 하나 더 돌린다고 생각하자
Replication controller 가 pod 두개 돌리는 것을 도와준다.
만약 단일 pod 시스템에서 replication cotroller를 사용하지 못하는가 ?
단일 pod에서 replication controller 사용가능하다 .
Even if you have a single pod, the replication controller can help by automatically bringing up a new
pod when the existing one fails.
Pod 에 문제 생기면 자동으로 pod를 생성한다 .
Thus the replication controller ensures that the specified number of pods are running at all times,
Replication controller는 정해진 pod 수만큼 돌아가도록 유지하는 역할
로드밸런싱과 스케일링 Load Balancing & Scaling
Load balancing 에 있어서 replication controller 가 수행한다.
유저가 늘어나면 pod를 늘리다가 다른 노드에 걸쳐 pod를 확장한다.
Replication controller. Replica set 같은 목적을 가지지만 엄밀히 다르다 .
Replication controller is the older technology that is being replaced by replica set.
Replica set is the new recommended way to set up replication.
옛날엔 replication controller를 사용했다면 지금은 replica set 으로 한다.
Replication controller에 대한 yaml 파일을 만들자
4 대 속성
ApiVersion, kind , metadata, spec
Spec 작성이 조금 다르다 .
Template을 통해 정의한다.
Spec -> template -> (metadata, spec ) 정의
그렇게 하면 metadata 가 두개 생긴다.
하나는 replication controller 에 대한 metadata
두번째는 pod 에 대한 metadata
Replica 개수에 대해서도 정의해야한다
Spec 아래의 template와 replica 는 형제 사이다.
같은 라인에 두자!
r-c 생성과 가져오기, pod 확인하기
상기의 방법은 replication controller를 사용한 방법이다.
version 을 apps/v1 으로 명시
ReplicaSet
그리고 selector를 필요로 한다 .
생성하기
Labels and selector에 관하여
Pod 세개를 이용하는 web application 이 있다고 가정하자
r-c 또는 replica는 3개의 pod이 돌아가고 있다고 보장해야한다.
Replica set은 pod을 모니터링 한다.
Replica set 은 어느 pods을 감시해야하는지 어떻게 알까?
Labeling 이 중요한 이유
Pod 에서 labels 를 정의한다.
Selector matchlables에서 모니터링할 labels 을 명시하면 된다 .
This way the replica set knows which pods to monitor.
쿠버네티스에서 위와 같은 방식으로 많이 작동한다.
3개의 pod가 돌아가고 있다고 치자
R-c 와 replica set의 차이점
r-c 에는 어떤 pod 를 연결해야할지 명시되어있지 않기 때문에 새로 만든다.
Replica set 에는 matching labels 이 있으니까 연결한다 .
Replica 수를 변경하는 방법 세가지
1번 yaml 파일로가서 숫자 변경
2,3 scale 명령어를 사용하기
29. Practice Test - ReplicaSets
시험을 보자
1. How many PODs exist on the system?
kubectl get pods
2. How many ReplicaSets exist on the system?
kubectl get ReplicaSets
3. How about now? How many ReplicaSets do you see?
4. How many PODs are DESIRED in the new-replica-set?
4개
5. What is the image used to create the pods in the new-replica-set?
describe로 찾기
6. How many PODs are READY in the new-replica-set?
0
7. Why do you think the PODs are not ready?
image 문제
8. Delete any one of Pods .
kubectl delete pods --all
9. How many PODs exist now?
4
10. Why are there still 4 PODs, even after you deleted one?
레플리카셋에서 지정했으므로
11. Create a ReplicaSet using the replicaset-definition-1.yaml file located at /root/.
There is an issue with the file, so try to fix it.
1) ls 로 확인
2) kubectl create -f replicaset-definition-1.yaml 명령어로 강제 실행
error: resource mapping not found for name: "replicaset-1" namespace: "" from "replicaset-definition-1.yaml": no matches for kind "ReplicaSet" in version "v1"
ensure CRDs are installed first
3) vi replicaset-definition-1.yaml 로 확인
vi 로 열어서 수정하자
apps/v1 으로
12. Fix the issue in the replicaset-definition-2.yaml file and create a ReplicaSet using it.
kubectl create -f replicaset-definition-2.yaml 강제 실행하면
The ReplicaSet "replicaset-2" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"tier":"nginx"}: `selector` does not match template `labels`
tier를 nginx 로 맞춰주자
13. Delete the two newly created ReplicaSets - replicaset-1 and replicaset-2
kubectl get rs 로 레플리카셋을 먼저 확인
kubectl delete rs replicaset-1
레플리카셋 삭제하기
14.
Fix the original replica set new-replica-set to use the correct busybox image.
Either delete and recreate the ReplicaSet or Update the existing ReplicaSet and then delete all PODs, so new ones with the correct image will be created.
rs 수정하기
kubectl edit rs new-replica-set
image busybox777 에서 busybox 로 수정
수정해도 파드가 실행되지 않는다. 기존의 파드들을 삭제하고
rs 가 다시 파드를 생성할때 수정된 이미지로 생성된다.
파드를 삭제하자!
15.
Scale the ReplicaSet to 5 PODs.
Use kubectl scale command or edit the replicaset using kubectl edit replicaset.
kubectl scale rs new-replica-set --replicas=5
레플리카 수 늘리기
16.
Now scale the ReplicaSet down to 2 PODs.
Use the kubectl scale command or edit the replicaset using kubectl edit replicaset.
31. Deployments
Webserver를 운영하고 있다고 가정하자.
각 instance들이 운영되고 있는데 새로운 버전의 애플리케이션이 완성되면 인스턴스에 해당 사항을 업그레이드 해야한다.
한번에 업데이트하는 것이 아니라 인스턴스를 하나씩 교체하면서 업그레이드 하는 것을 rolling updates 라고 한다.
Pods를 관리하는 것은 replication controller, replicaset
Pods를 상위에서 관리하는 단위를 deployment라고 한다.
Pods 를 중지시키거나 업데이트 하는 작업을 문제없이 진행한다.
마찬가지로 yaml 파일로 생성한다.
Kind는 Deployment
Deployment 를 생성하면 자동으로 replicaset,pods도 생성된다.
Deployments가 생성될떄 쿠버네티스 객체 deployment( 이것도 객체 타입)가 생성된다.
Kubectl get all 로
돌아가는 모든 객체를 확인할 수 있다.
32. Certification Tips
시험꿀팁 그런 건데,
시험 칠 때 yaml 파일을 수동으로 작성하는 건 부담된다.
Yaml 파일을 직접 만들지말고
Kubectl run 명령어로 빠르게 kube 객체들을 만들 수 있다.
kubectl Usage Conventions | Kubernetes
Where kubectl create will create a resource, kubectl run will create and run the resource.
Create an NGINX Pod
kubectl run nginx --image=nginx
Generate POD Manifest YAML file (-o yaml). Don't create it(--dry-run)
kubectl run nginx --image=nginx --dry-run=client -o yaml
Create a deployment
kubectl create deployment --image=nginx nginx
Generate Deployment YAML file (-o yaml). Don't create it(--dry-run)
kubectl create deployment --image=nginx nginx --dry-run=client -o yaml
Generate Deployment YAML file (-o yaml). Don't create it(--dry-run) with 4 Replicas (--replicas=4)
kubectl create deployment --image=nginx nginx --dry-run=client -o yaml > nginx-deployment.yaml
Save it to a file, make necessary changes to the file (for example, adding more replicas) and then create the deployment.
kubectl create -f nginx-deployment.yaml
OR
In k8s version 1.19+, we can specify the --replicas option to create a deployment with 4 replicas.
kubectl create deployment --image=nginx nginx --replicas=4 --dry-run=client -o yaml > nginx-deployment.yaml
33. Practic Test – Deployments
1. How many PODs exist on the system?
2. How many ReplicaSets exist on the system?
kubectl get rs
3. How many Deployments exist on the system?
kubectl get deploment
4. How many Deployments exist on the system now?.
5. How many ReplicaSets exist on the system now?
6. How many PODs exist on the system now?
7. Out of all the existing PODs, how many are ready?
0 개
8. What is the image used to create the pods in the new deployment?
9. Why do you think the deployment is not ready?
이미지 문제
10. Create a new Deployment using the deployment-definition-1.yaml file located at /root/.
There is an issue with the file, so try to fix it.
수정후
kubectl create -f 파일이름
11. Create a new Deployment with the below attributes using your own deployment definition file.
Name: httpd-frontend;
Replicas: 3;
Image: httpd:2.4-alpine
kubectl create deployment --image=httpd:2.4-alpine httpd-frontend --dry-run=client -o yaml > frontend-deployment.yaml
생성 후
vi 로 수정
35. Services
Services enable communication between various components within and outside of the application. Kubernetes
services helps us connect applications together with other applications or users.
Service를 통해 component, user 들 이 통신할 수 있다.
Application pod, backend pod, database pods 다 service를 통해서 통신한다.
외부 통신
파이썬 pod를 구동한다고 생각하자
쿠버네티스 노드의 ip는 192.168.1.2
나의 랩탑 ip는 192.168.1.10
Pod 네트워크의 ip 범위는 10.244.0.0
Pod의 ip는 10.244.0.2
Ssh를 통해 10.244.0.2 로 바로 접속하면 웹페이지를 접속할 수 있다.
Curl http://10.244.0.2
하지만 10.244.0.2 의 ip 주소는 node 안에서만 정의된 것
외부에서 10.244.0.2 로 접속 못함
Ssh 없이 url 로 접소하는 방법은?
30008 포트를 service로 지정
랩탑에서 node ip와 포트를 통해 접속한다.
192.168.1.2:30008
Service는 마찬가지로 kube 객체이다.
One of its use case is to listen to a port on the Node and forward requests on that port to a port
on the POD running the web application.
Service가 자동으로 운영중인 pod로 연결시켜준다.
This type of service is known as a NodePortservice because the service listens to a port on the Node
and forwards requests to PODs.
Node port service라 부른다.
Service의 종류
Node port
NodePortwere the service makes an internal POD accessible on a Port on the Node.
외부에서 내부 pod에 접근하게 도와주는 것
Cluster ip
And in this case the service creates a virtual IP inside the cluster to enable communication between
different services such as a set of front end servers to a set of back end servers.
다른 service 끼리 소통할 수 있도록 가상의 ip를 만든다.
Load balancer
The third type is a LoadBalancer, were it provisions a load balancer for our service in supported cloud
providers.
내가 아는 load balancer 맞는가 ??
노드를 자세히 확인하면 3개의 포트가 관여한다.
웹서버가 돌아가는 80 타켓 포트
Service 스스로 가지는 port
The service is in fact like a virtual server inside the node inside the cluster.
Service는 가상의 서버라고 생각하자
가상의 ip도 가지고 있다. (10.106.1.12) cluster ip of server
노드 port 30008
노드 포트는 30000~ 32767 범위
Service 만들기
마찬가지로 yaml 로 만듬 .
apiVersion 은 v1
kind: Service
spec 이 조금 다르다.
Targetport 80은 웹서버
그냥 port 도 target port랑 똑같이 한다.
Nodeport는 30008
순서 조심하기
포트에 대한 정의는 있지만 어느 pod에 연결될지는 정보가 없다.?
Ports 아래에 selector 부분에 pod의 labels 정보를 넣는다 .
Service 생성하기~
Pod가 여러 개일때는 어떻게 작동하는가”?
Selector에 이름만 제대로 지정해놨다면
알아서 자동으로 분배해준다.
알고리즘은 랜덤으로 한다고 한다.
노드가 여러 개인 경우
Service를 만들면 쿠버네티스가 자동으로 노드를 거쳐 service를 만든다
모든 노드에 service를 하나씩 만들 필요없다.
36. Services Cluster IP
Pod의 ip는 정적이지 않다. => pod이 제거되고 생성될때마다 ip가 달라진다.
그럼 어떻게 connection을 유지하는가 ?
Service 가 중간에 알아서 배정해준다.
중간에서 다 취합해주는걸 cluster IP 라고 부른다.
타입은 clusterip
Selector 를 통해서 pod 와 연결한다.
37. Service – Loadbalancer
Type: : LoadBalnacer
로드 밸런싱을 지원하는 클라우드 플랫폼에서 kube 로드밸런서를 사용할 수 있다.
38. practice test services
1. How many Services exist on the system?
2. That is a default service created by Kubernetes at launch.
3. What is the type of the default kubernetes service?
4. What is the targetPort configured on the kubernetes service?
6443
5. How many labels are configured on the kubernetes service?
2개
6. How many Endpoints are attached on the kubernetes service?
1개
7. How many Deployments exist on the system now?
1개
8. What is the image used to create the pods in the deployment?
9.
Are you able to accesss the Web App UI?
Try to access the Web Application UI using the tab simple-webapp-ui above the terminal.
no
10. Create a new service to access the web application using the service-definition-1.yaml file.
11. Access the web application using the tab simple-webapp-ui above the terminal window.
40. Namespaces
처음에 pod등 객체를 만들면
Default namespace 에 생성된다.
우리가 이때까지 만든 객체들은 default namespace 안에서 통용된다.
Kube-system
Kube-public
이렇게 3개의 namespace 가 존재한다.
Name space에 각기 다른 제약조건을 만들 수 있다.
Namespace 안에서 객체들은 단순 name으로 부른다.
다른 namespace의 객체를 부를 때
url 구성
원래는 default 만 가져온다
다른 namespace의 뭔가를 가져올려면
--namespace=kube-system 이런 식으로 사용한다.
만약 옵션에 namespace를 넣으면 별개의 namespace에 객체를 만들 수 있다.
또는 metadata에 namespace 데이터를 넣어서 만들 수도 있다.
namespace를 만드는 방법
Default namespace를 변경하는 방법
Kubectl config set-context $(kubectl config current-context) –namespace=prod
모든 namespace내의 pod를 확인하는 방법
Kubectl get pods –all-namespaces
resource quota를 이용해 네임스페이스 안에 있는 자원을 제한할 수 있다.
41. Practice Test – Namespaces
1. How many Namespaces exist on the system?
kubectl get ns
2. how many pods exist in the research namespace?
kubectl get pods --namespace=reseacrh
3. create a pod in the finance namespace.
kubectl run redis --image=redis --namespace=finance -o yaml
4. Which namespace has the blue pod in it?
kubectl get pods --all-namespaces
5. Access the Blue web application using the link above your terminal!!
6. What DNS name should the Blue application use to access the database db-service in its own namespace - marketing?
You can try it in the web application UI. Use port 6379.
같은 네임스페이스에서 dns는 name 으로 할 수 있다.
7. What DNS name should the Blue application use to access the database db-service in the dev namespace?
You can try it in the web application UI. Use port 6379.
db-service.dev.svc.cluster.local
이름.네임스페이스.타입.~
43. Imperative vs Declarative
Imperative는 방법에 집중
Declarative는 목적지에 집중
Imperative는 하나 하나 명시해야하나
Declarive는 선언적
Declarive는 명료하다.
업그레이드에 용이하다.
Imperative 는 손이 많이 간다.
Imperative 한 방법으로 생성하면 기록을 확인하기 어렵다.
만약 kubectl 로 수정한다면 kube 메모리 상에서만 변경 사항이 저장된다.
실제 yaml 파일이 변경되지 않는다.
replace를 통해 파일을 교체 -> local yaml 파일도 변경된다.
--force 통해 삭제?
명령형에서는 객체를 업데이트할떄 먼저 객체가 돌아가는지 확인해야한다.
명령형은 정말 신경쓸게 많고 귀찮다.
apply를 하면 객체가 있는지 없는지 확인하고 없으면 생성한다.
여러 개를 만들고 싶으면 경로를 주면 된다.
파일에 변화가 있을때만 업데이트한다.
여러 파일을 한번에 업데이트하고 싶으면 apply 가 유리하다.
44. Certification Tips - Imperative Commands with Kubectl
While you would be working mostly the declarative way - using definition files, imperative commands can help in getting one time tasks done quickly, as well as generate a definition template easily. This would help save considerable amount of time during your exams.
Before we begin, familiarize with the two options that can come in handy while working with the below commands:
--dry-run: By default as soon as the command is run, the resource will be created. If you simply want to test your command , use the --dry-run=client option. This will not create the resource, instead, tell you whether the resource can be created and if your command is right.
-o yaml: This will output the resource definition in YAML format on screen.
Use the above two in combination to generate a resource definition file quickly, that you can then modify and create resources as required, instead of creating the files from scratch.
POD
Create an NGINX Pod
kubectl run nginx --image=nginx
Generate POD Manifest YAML file (-o yaml). Don't create it(--dry-run)
kubectl run nginx --image=nginx --dry-run=client -o yaml
Deployment
Create a deployment
kubectl create deployment --image=nginx nginx
Generate Deployment YAML file (-o yaml). Don't create it(--dry-run)
kubectl create deployment --image=nginx nginx --dry-run=client -o yaml
Generate Deployment with 4 Replicas
kubectl create deployment nginx --image=nginx --replicas=4
You can also scale a deployment using the kubectl scale command.
kubectl scale deployment nginx --replicas=4
Another way to do this is to save the YAML definition to a file and modify
kubectl create deployment nginx --image=nginx --dry-run=client -o yaml > nginx-deployment.yaml
You can then update the YAML file with the replicas or any other field before creating the deployment.
Service
Create a Service named redis-service of type ClusterIP to expose pod redis on port 6379
kubectl expose pod redis --port=6379 --name redis-service --dry-run=client -o yaml
(This will automatically use the pod's labels as selectors)
Or
kubectl create service clusterip redis --tcp=6379:6379 --dry-run=client -o yaml (This will not use the pods labels as selectors, instead it will assume selectors as app=redis. You cannot pass in selectors as an option. So it does not work very well if your pod has a different label set. So generate the file and modify the selectors before creating the service)
Create a Service named nginx of type NodePort to expose pod nginx's port 80 on port 30080 on the nodes:
kubectl expose pod nginx --type=NodePort --port=80 --name=nginx-service --dry-run=client -o yaml
(This will automatically use the pod's labels as selectors, but you cannot specify the node port. You have to generate a definition file and then add the node port in manually before creating the service with the pod.)
Or
kubectl create service nodeport nginx --tcp=80:80 --node-port=30080 --dry-run=client -o yaml
(This will not use the pods labels as selectors)
Both the above commands have their own challenges. While one of it cannot accept a selector the other cannot accept a node port. I would recommend going with the kubectl expose command. If you need to
specify a node port, generate a definition file using the same command and manually input the nodeport before creating the service.
Reference:
https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
https://kubernetes.io/docs/reference/kubectl/conventions/
45. Practice Test - Imperative Commands
2.
Deploy a pod named nginx-pod using the nginx:alpine image.
Use imperative commands only.
3.
Deploy a redis pod using the redis:alpine image with the labels set to tier=db.
Either use imperative commands to create the pod with the labels. Or else use imperative commands to generate the pod definition file, then add the labels before creating the pod using the file.
4. Create a service redis-service to expose the redis application within the cluster on port 6379.
Use imperative commands.
Kubectl expose pod redis –port 6379 –name redis-service
도 가능하다.
Expose를 하면 자동으로 clusterIP 서비스로 간다.
5. Create a deployment named webapp using the image kodekloud/webapp-color with 3 replicas.
Try to use imperative commands only. Do not create definition files.
6. Create a new pod called custom-nginx using the nginx image and expose it on container port 8080.
7. Create a new namespace called dev-ns.
Use imperative commands.
8. Create a new deployment called redis-deploy in the dev-ns namespace with the redis image. It should have 2 replicas.
Use imperative commands.
9. Create a pod called httpd using the image httpd:alpine in the default namespace. Next, create a service of type ClusterIP by the same name (httpd). The target port for the service should be 80.
Try to do this with as few steps as possible.
Kubectl run –help 를 통해서
expose 명령어를 사용하면 외부로 서비스를 노출시킬 수 있다.
47. Kubectl Apply Command
So when you run the apply command, if the object does not already exist, the object is created.
Apply 를 사용했는데 pod이 없다면 생성한다.
An object configuration similar to what we created locally is created within Kubernetes, but with additional
fields to store status of the object.
객체가 생성되면 kube live object configuration 파일도 생성된다.
status라는 옵션이 추가된다.
This is the life configuration of the object on the Kubernetes cluster.
This is how Kubernetes internally stores information about an object, no matter what approach you use
to create the object.
Yaml 파일은 json 포멧으로 변경된다.
Local yaml 파일, last applied configuration json, live object configuration
이 세개가 존재
Apply 가 실행되고 yaml 파일의 업데이트 사항이 있으면
Live object conf 를 비교후 업데이트 하고
Json 파일을 업데이트 한다.
세가지 파일이 있기 때문에 kube 가 업데이트, 수정 사항을 알 수 있다.
Yaml 파일은 로컬 스토리지
Live object config는 kube memory에
Json 파일은 사실 live object config에
annotations: kubectl.kubernetes.io/last-applied-configuration:
에 json 형식으로 숨어있다.
Apply는 세 파일다 영향을 끼치는 것을 알고 선언,
선언형과 명령형 썩어쓰지 말자