배포 최소 단위
Pod > container -> 하나의 pod는 여러 containers를 가질 수 있다.
그러나 보통 pod당 하나의 container(같은 종류의)을 담는다.
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
type: front-end
spec:
containers:
- name: nginx-container
image: nginx
ReplicaSet은 selector에 있는 label과 같은 pods를 모두 관리한다.
즉, replicaSet을 만들기 전에 있던 pod도 selector의 label만 같으면 replica 개수에 포함시켜 모니터링한다.
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myapp-replicaset
labels:
apps: myapp
type: front-end
spec:
template:
metadata:
name: myapp-pod
labels:
app: myapp
type: front-end
spec:
containers:
- name: nginx-container
image: nginx
replicas: 3
selector:
matchLabels:
type: front-end
replicas 개수를 늘리기 위해선 2가지 방법이 있다.
1. kubectl replace -f <file-name>
2. kubectl scale --replicas=<replica-num> -f <file-name>
3. kubectl scale --replicas=<replica-num> replicaset <replicaset-name>
주의할 점은, kubectl scale 명령과 파일 이름을 input으로 넣어도 자동적으로 파일 안에 replicas 개수가 업데이트되지 않는다는 점이다.
Covers the replicasets roles and plus, have capability to upgrade the underlying instances seamlessly using rolling updates, undo changes, pause, and resume changes as required
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
labels:
apps: myapp
type: front-end
spec:
template:
metadata:
name: myapp-pod
labels:
app: myapp
type: front-end
spec:
containers:
- name: nginx-container
image: nginx
replicas: 3
selector:
matchLabels:
type: front-end
application들을 이어주는 역할을 한다.
NodePort
내부의 pod가 node의 port를 통해 접근될 수 있게 하는 것
* targetPort: 타겟 pod의 port
* port: service의 port (필수로 지정)
* nodePort: node의 port (300000 ~ 32767)
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
type: NodePort
ports:
- targetPort: 80
port: 80
nodePort: 30008
selector:
app: myapp
type: front-end
* selector 필드를 통해 매칭되는 파드를 연결시켜준다.
그래서, 매칭되는 여러개의 파드를 랜덤하게 load balancing하는 역할도 수행할 수 있다.
* 만약 여러 노드에 각각 pod가 하나씩 배치되어있고, 하나의 NodePort 서비스를 만든다면, kubernetes가 자동으로 node 전체에 확장된 서비스를 만든다.
그러면 각 node의 IP와 같은 port 번호를 통해 각각의 pod에 접근이 가능하다.
apiVersion: v1
kind: Service
metadata:
name: back-end
spec:
type: ClusterIP
ports:
- targetPort: 80
port: 80
selector:
app: myapp
type: front-end
* type을 지정하지 않으면 default service로 ClusterIP로 만들어짐
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
type: LoadBalancer
ports:
- targetPort: 80
port: 80
nodePort: 30008
selector:
app: myapp
type: front-end
시험에서 적절히 두가지 방법을 사용할줄 알아야한다.
kubectl create -f nginx.yaml
kubectl edit deployment nginx
* 여기서 열리는 file은 위의 local file인 nginx.yaml과 다른 파일이다.
edit 명령어로 열리는 파일은 kubernetes memory에 올라가있는 definition file로, 그 변화가 현재 살아있는 object에 적용된다.```bash
kubectl replace -f nginx.yaml
kubectl replace --force -f nginx.yaml
```
* force 옵션을 쓰면 object를 완전히 삭제하고 다시 만들게 된다.
## Declarative
* Create Objects
```bash
kubectl apply -f nginx.yaml
```
```bash
kubectl apply -f /path/to/config-files
```
* Update Objects
```bash
kubectl apply -f nginx.yaml
```
* replace와 다른점은, object가 사전에 미리 존재해있지 않다면 replace는 에러를 낸다.
## kubectl apply command
> apply 명령을 통해 local file의 내용을 kubernetes 안의 실제 live한 object의 정의 파일에 적용시키는 역할을 한다.
> 또한, last applied configuration을 저장해두기 때문에 apply 명령을 통해 수정된 local file을 적용시키면 변화를 감지하여 적용할 수 있다.> create 나 replace 명령어는 이런 last applied configuration을 저장하지 않는다.
#CKA
#CKA/Core_Concepts