반응형

Pod

개념

쿠버네티스에서 실제로 컨테이너를 묶어서 관리하는 단위

설정

apiVersion: v1
kind: Pod
metadata:  
  name: simple-pod          (Pod 이름)
  labels: 
    app: simple-pod         (오브젝트를 식별하는 레이블)
spec:
  containers:
  - name: simple-pod        (컨테이너 이름)
    image: ~~~              (컨네이너에서 사용할 이미지)
    ports:
    - containerPort: 8080

Pod 생명주기

Pending -> Running

Successed

Failed

Unknown

컨테이너 진단

  • ivenessProbe

    컨테이너가 실행됐는지 확인

    실패시 컨테이너를 종료시키고 재시작 정책에 따라서 재시작

  • readinessProbe

    컨테이너 실행된 후 실제로 서비스 요청에 응답할 수 있는지 진단

    컨테이너가 실제로 트래픽을 받을 준비가 되었음을 확인할 수 있어 유용함

초기화 컨테이너(Init Container)

  • 앱 컨테이너가 실행 되기 전 Pod 를 초기화 한다.

  • 여러개 구성 가능하며 실행 순서는 템플릿에 명시한 순서를 따른다.

  • 실패시 성공할때 까지 재시작한다.

  • readinessProbe 를 지원하지 않는다 - Pod 가 준비되기 전에 실행후 종료되기 때문

  • 설정

    .spec.initContainers[] 의 하위 필드

      apiVersion: v1
      kind: Pod
      metadata:  
          name: simple-pod
          labels: 
              app: simple-pod
      spec:
          initContainers:
          - name: 
            image:
            command        

파드 인프라 컨테이너

pause 컨테이너

  • Pod Infrastructure Container (파드 인프라 컨테이너)
  • 모든 Pod 에서 항상 실행된다
  • 다른 컨테이너의 부모 역할을 한다
  • Pod 안 다른 컨테이너들은 pause 컨테이너가 제공하는 네트워크를 사용
  • pause 컨테이너 재시작시 Pod 안 모든 컨테이너 재시작됨
    c34dff11289b        arisu1000/simple-container-app   "./simple-container-…"   41 minutes ago      Up 41 minutes                           k8s_simple-pod_simple-pod_default_112e5cb1-101b-4cb6-a591-c83c6171cce5_0
    67c790777792        k8s.gcr.io/pause:3.2             "/pause"                 41 minutes ago      Up 41 minutes                           k8s_POD_simple-pod_default_112e5cb1-101b-4cb6-a591-c83c6171cce5_0

스태틱 Pod

  • kube-apiserver 를 통하지 않고 kubelet 이 직접 실행하는 Pod
  • 조회는 가능하지만 명령 실행은 불가능(직접 edit 등 불가능)
  • 시스템 파드 실행용도로 많이 사용
  • 스태틱 Pod 경로 : /etc/kubernetes/manifests

자원 할당

  • requests 최소자원, limits 최대자원

    .spec.containers[].resources.limits.cpu

    .spec.containers[].resources.limits.memory

    .spec.containers[].resources.requests.cpu

    .spec.containers[].resources.requests.memory

  • requests 만 설정했을 경우 해당 값보다 더 많이 사용할 수 있기 때문에 limits 설정을 해야 Out of Memory 를 피할수 있다.

  • Memory : Exa, Peta, Tera, Giga, Mega, Kilo (맨 첫글자 사용)

  • CPU : 소수점일 경우 1개 코어에 해당하는 연산능력을 의미( 0.1 일경우 1코어의 10%만 활용)

Pod 의 환경 변수

.spec.conainers[].env[] 하위 필드

  • name
  • value
  • valueFrom
  • fieldRef
  • fieldPath
  • resourceFieldRef
  • containerName
  • resource

출처 : 쿠버네티스 입문 - 90가지 예제로 배우는 컨테이너 관리자 자동화 표준 (동양북스)

728x90
반응형
반응형

현재 시스템의 구성은 다음과 같다

 

MasterNode, Worker1, Worker2

 

여기에 테스트를 위해서 mysql 을 열려놨다. 해당 yaml 은 다음과 같다. 

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: spring
  name: deploy-mysql
  labels:
    app: mysql
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: MYSQL_ROOT_PASSWORD
        - name: MYSQL_DATABASE
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: MYSQL_DATABASE
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: MYSQL_USER
        ports:
        - containerPort: 3306
          name: mysql
          protocol: TCP
        volumeMounts:
        - mountPath: "/var/lib/mysql"
          name: mysql-volume
          subPath: dbdata
      volumes:
      - name: mysql-volume
        persistentVolumeClaim:
          claimName: mysql-pvc

그런데 한가지 문제가 생겼다. 

나는 K8S 를 사용하기 위해 virtual box 에서 master, worker1, worker2 이렇게 순서대로 헤드리스로 기동을 시킨다.

그런데 가끔 worker2 가 Ready 가 되기 전에 deployment 의 replicaset 이 같은 노드에 할당 되는 상황이 발생했다.

그러다 보니 pod 가 정상적으로 뜨지 않게 되었다. 

 

그냥 Pod 를 실행시키는 거라면 nodeselector 를 설정하면 될텐데 Deployment는 어떻게 하는지 몰라서 찾아보니 다음과 같이 spec 에 affinity 를 추가하는 방법을 찾을 수 있었다. 

      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - mysql
            topologyKey: "kubernetes.io/hostname"

 

위 설정에는 affinity 설정중 podAntiAffinity 설정을 추가하였다. 설정을 차례대로 해석하면 다음과 같다.

 

podAntiAffinity : 이 pod 가 실행될때 다음 값이 참이면 안된다.

requiredDuringSchedulingIgnoredDuringExecution : 반드시 만족해야 한다. (또다른 설정으로는 preffered 가 있다.)

matchExpressions: label 이 key 는 app 이고 값은 mysql 인 label을 찾는다.

 

결과적으로 label 이 app 이고 값이 mysql 인 pod 가 존재하는 node 에서는 pod 가 실행되지 않는다.

그래서 replicas 가 2로 설정되어있기 때문에 각각의 pod 는 각각의 node 에 위치하게 된다. 

 

master01@master01-VirtualBox:~/k8s/mysql$ kubectl get po -n spring -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP            NODE                  NOMINATED NODE   READINESS GATES
deploy-mysql-84f7bb885-rn9tz   1/1     Running   1          27h   10.244.1.80   worker01-virtualbox   <none>           <none>
deploy-mysql-84f7bb885-zqlmw   1/1     Running   1          26h   10.244.2.64   worker02-virtualbox   <none>           <none>

 

이거 이외에도 다양한 표현식으로 컨트롤이 가능하다. 

더 자세한 것은 아래 도큐먼트 참고하길 바란다.

 

v1-18.docs.kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/

728x90
반응형
반응형

1. PV (Persistent Volume)

 

- PV는 클러스터 리소스 이다. 

 

- volumeModes

  Filesystem : Pod 의 디렉토리에 마운트 된다.

  Block

 

- PersistentVolumeReclaimPolicy (PVC 삭제시 PV 데이터에 대한 정책)

  - Retail : 그대로 보존

  - Recycle : 재사용시 기존 pv 데이터들 삭제 후 재사용 (이건 사용 안함)

  - Delete : 볼륨 삭제 

 

- RecaimPolicy Update

  kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

 

2. PVC (Persistent Volume Claim)

 

pv 와 pvc 는 1:1 바인딩이며 pvc 가 요청하는 볼륨이 pv 에 없으면 무한 대기 한다.

따라서 바인딩을 위해서는 pv와 pvc 의 storageClassName 이 같아야 한다.

 

pod 이 사용중인 pvc 는 삭제가 불가능 하다.

 

3. 생성 Yaml (mysql 에서 사용하려고 만든 yaml 파일 이다.)

apiVersion: v1
kind: PersistentVolume
metadata:
  namespace: spring
  name: mysql-pv
spec:
  storageClassName: local-path
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 2Gi
  hostPath:
    path: /home/master01/k8s/mysql-data
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  namespace: spring
  name: mysql-pvc
spec:
  storageClassName: local-path
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

 

참고 사이트

 

https://kubernetes.io/ko/docs/concepts/storage/persistent-volumes/

https://kubernetes.io/ko/docs/tasks/administer-cluster/change-pv-reclaim-policy/

 

728x90
반응형
반응형

[K8S] ## K8S 설치시 Trouble Shooting

- kubeadm init 했는데 다음과 같이 나오는 경우

[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.

Unfortunately, an error has occurred:
timed out waiting for the condition
This error is likely caused by:
- The kubelet is not running
- The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)
If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI, e.g. docker.
Here is one example how you may list all Kubernetes containers running in docker:
- 'docker ps -a | grep kube | grep -v pause'
Once you have found the failing container, you can inspect its logs with:
- 'docker logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster

 

1. docker Cgroup 이 systemd 로 설정되어있을 경우

/etc/docker/daemon.json 파일에 아래 문구 추가한다.

{
	"exec-opts": ["native.cgroupdriver=systemd"]
}

그리고
systemctl daemon-reload
systemctl restart docker

2. 로그 확인

- 'journalctl -xeu kubelet' 

이 명령어를 실행 하면 아래와 같이 로그가 남았다. 

Apr 30 22:19:38 master kubelet: W0430 22:19:38.226441    2372 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Apr 30 22:19:38 master kubelet: E0430 22:19:38.226587    2372 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

 

내 경우에는 위에 2.  /env/environment 설정 에 보면 **no_proxy** 항목에 현재 K8S 가 설치된 Machine 의 IP 를 추가했더니 해결이 되었다.

- kubeadm join 했는데 다음과 같이 나올 경우

[preflight] Running pre-flight checks
error execution phase preflight: [preflight] Some fatal errors occurred:
    [ERROR FileAvailable--etc-kubernetes-kubelet.conf]: /etc/kubernetes/kubelet.conf already exists
    [ERROR Port-10250]: Port 10250 is in use
    [ERROR FileAvailable--etc-kubernetes-pki-ca.crt]: /etc/kubernetes/pki/ca.crt already exists
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
To see the stack trace of this error execute with --v=5 or higher

    VM 에서 다음과 같이 kubeadm join 을 했는데 에러가 났을경우 (node가 2개인데 2번째 노드 구성시)

    kubeadm reset 을 한번 실행하고 다시 join 명령어를 실행해준다.

728x90
반응형
반응형

몇번의 시도 끝에 Virtual Box 에 Kubernetes 설치를 성공했다.

총 Master1 개, Worker 2 개로 구성을 했다.

 

1. Virtual BOX 환경설정

    - 네트워크 

        - 네트워크 이름 : k8s-network

        - 네트워크 CIDR : 10.0.1.0/24

        - 네트워크 옵션 : DHCP 지원 체크

2. Machine 설정 (화면캡쳐 없음 ㅠㅠ)

    - 일반 : 고급

        - 클립보드 공유 : 양방향

        - 드래그 앤 드롭 : 양방향

    - 시스템 : 프로세서 

        - 개수 : 2

    - 네트워크 : 어댑터 1

        - 다음에 연결됨 : Nat 네트워크

        - 이름 : k8s-network  (미리 만들어야된다.)

    - 네트워크 : 어댑터 2

        - 다음에 연결됨 : Nat    

    - 공유폴더 (Optional)

        - 폴더 설정, 마운트 지정

3. 설치

4. 완료후 설정 (Optional) 

    - 장치 : 게스트 확장 CD 삽입 -> 설치

5. Ubuntu 설정 

    1. 관리자 계정으로 시작

        sudo -i

    2.  /etc/environment 설정 (Optional proxy를 사용하는 경우만 해당됨) 

        export http_proxy=http://[IP]:[PORT]

        export https_proxy=http://[IP]:[PORT]

        export no_proxy=IP...

    3. 가상메모리 미사용

swapoff -a && sed -i '/ swap / s/^/#/' /etc/fstab

    4. 인증서 설정 (Optional) 

        /usr/local/share/ca-certificates/ 에 인증서 복사

        update-ca-certificates 실행

    5. 도커 설치

apt update
apt install -y docker.io
cat << EOF > /etc/docker/daemon.json
{
	"exec-opts": ["native.cgroupdriver=systemd"]
}
EOF

    6. 프록시 추가 (Optional) 

vi /lib/systemd/system/docker.service

        [Service]

        Environment="HTTP_PROXY=http://[IP]:[PORT]/" "HTTPS_PROXY=http://[IP]:[PORT]/" "NO_PROXY=localhost,127.0.0.1,10.0.1.7"

 

    7. 도커 재기동

systemctl daemon-reload
systemctl restart docker

    8. K8S 패키지 매니저 레파지토리 추가

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg -k | apt-key add -
cat << EOF > /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF

    9. K8S 설치

apt update -y
apt-get update
apt-get install -y kubelet kubeadm kubectl

        1. Master Node 설정

            1. kubeadm init

kubeadm init --pod-network-cidr=10.244.0.0/16

                설치후 아래와 같이 메세지가 나오면 정상적으로 설치 완료

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:
kubeadm join 10.0.1.7:6443 --token bfq4lq.1k5qiesq8norkwck \

--discovery-token-ca-cert-hash sha256:66249ed983b26844267631ae0a061c7d02386941e154341bc669c72add72afeb    

            2. kubectl 구성

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

            3. pod network 플러그인 설치

kubectl apply -f http://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

        2. Worker Node 설정

kubeadm join 10.0.1.7:6443 --token bfq4lq.1k5qiesq8norkwck \

--discovery-token-ca-cert-hash sha256:66249ed983b26844267631ae0a061c7d02386941e154341bc669c72add72afeb    

 

참고

docs.docker.com/engine/install/ubuntu/

kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

728x90
반응형

'Development > Docker&Kubernetes' 카테고리의 다른 글

[K8S] PV & PVC  (0) 2020.10.16
[K8S] Kubernetes 설치시 오류 조치  (2) 2020.10.13
VirtualBox 에 Kubernetes 올리기(k3s)  (0) 2020.09.11
맥북에 도커 설치.  (0) 2020.07.10
[K8S] Kubernetes secret 생성  (0) 2020.04.14
반응형

 

이 책이 최근에 나온 것을 알고 읽어봐야겠다라는 생각을 하고 있었는데 이렇게 리뷰어로 선정되어 읽게 되었다. 

 

우선 이 책의 목차를 보면 총 13개의 Chapter 로 구성되어있다.

 

1. 쿠버네티스란

2. 쿠버네티스 살펴보기

3. 아키텍처

4. 쿠버네티스 API 서버

5. 스케줄러

6. 쿠버네티스 설치

7. 인증과 사용자 관리

8. 인가

9. 승인제어

10. 네트워킹

11. 모니터링

12. 재해복구

13. 쿠버네티스 확장하기

 

Chapter 1 에서부터 6 까지는 쿠버네티스의 이론 적인 내용이 주로 설명되어있다. 단, 이 책은 운영에 대해서 초점을 맞춘 책이기 때문에 오브젝트 단위까지의 자세한 설명은 언급하지 않았다. 그리고 그 이후 Chapter 에서는 운영 환경에서 설정을 해줄수 있는 또는 해줘야 하는 인증, 승인에 대해서 알려주고 있다. 

 

이 책의 장점은 쿠버네티스 API 서버와 연관해서 인증, 인가, 승인제어 부분을 자세히 다뤄주고 있다. 쿠버네티스에가 가장 중요하다고 할 수 있는 API 에 대해서 어떻게 호출하는지, 또는 누가 어떤 API 를 호출 할수 있고 또는 없는지, 그런 설정들은 어떻게 해나갈수 있는지 차례대로 설명을 해준다. 

 

그런데 단점 부분이 좀 아쉽다. 읽다가 문뜩 드는 생각은 과연 이렇게 하면 잘 운영할 수 있는건가 라는 의문이 들게 된다. 생각보다 내용이 많지 않다는 것을 느꼈다. 내가 일부분 잘 이해를 못해서 그럴수는 있지만 사례에 대한 설명이나 예제가 좀 부족하지 않나라는 생각이 계속 들었다. 

 

 

728x90
반응형
반응형

오랜만에 Google 세미나에 다녀왔다.

 

지난 4월 9일 ~ 11일 미국에서 열렸던 Next '19 에서 발표된 내용들을 국내에서 소개하는 자리였다. 

총 3개의 트랙으로 진행되었고 각각의 트랙은 "인프라 현대화 및 하이브리드 클라우드", "데이터 매니지먼트", "스마트 애널리틱스" 로 나눠져 있었다. 

 

 


 

인프라 현대화와 하이브리드 클라우드 오버뷰 및 새로운 기능 소개 - 이재근, 구글 클라우드 Field Sales Representative

현재 시스템들이 온프레미스 형태로 운영되고 있는 환경들이 많다. 그러한 환경들을 컨테이너 형태로, 그리고 Google Cloud 를 사용할수 있도록 어떻게 가이드를 하는지 보여줬다. 빅뱅 형태도 있지만 쉽지는 않고 Lift&Shift 나 Improve&Move 라는 형태도 제시를 해줬다. 다양한 상황, 또는 환경에 대해서 분석하고 검토해서 Cloud 환경으로 변화할수 있도록  마련을 하고 있다고 한다. 

그러면서 소개된 제품들이 "벨로스트라타" 와 "Anthos" 이다. 벨로스트라타는 온프레미스 환경의 어플리케이션들을 Cloud 환경으로 이전할수 있도록 도와주는 제품이다. 그리고 Anthos 는 퍼블릭과 프라이빗 클라우드 환경에서의 개발, 배포, 보안, 운영을 통합해주는 제품이다. (자세한 것은 링크를 들어가서 보는게 더 좋을것 같다. ) 

특히 Anthos는 다른 세션들에서도 자주 언급이 되었다. 온프레미스 환경, 다양한 퍼블릭 클라우드를 여러개 동시 쓰는 환경에서 Anthos 가 도움을 줄 수 있는 툴이라는 면에서 매리트가 많아 보였다. (특히 국내 시장은 더욱더 ..)

 

하이브리드 클라우드의 미래 Anthos - 정명훈, 구글 클라우드 Customer Engineer

이번 세션에도 Anthos 에 대한 내용이었다. 그럼 과연 어떻게 동작을 하는 것일까?? 세션에서 들은것만 가지고 내용을 다 이해할 수는 없지만 일단 내가 이해한 내용을 설명해 보겠다. 

GCP 영역은 퍼블릭 클라우드이다. 그리고 vShpere 부분은 이제 온프레미스쪽 영역이다. 일단 그림을 보면 GKE Connect가 각각의 영역에 존재한다. 그리고 모든 통신은 이것을 통해서만 이루어 지는것 같았다. 일종의 gateway 같은 역할을 해주는것 같다. 아마도 연결 구간이 일원화 되어있기 때문에 보안 적인 측면에서도 괜찮겠지..라는 생각을 했다. 다만 스펙은 정확히 알지 못하니 어느정도의 트래픽을 감당해 줄수 있느냐가 관건일것 같다. 그리고 들으면서 궁금했던건 stackdriver 족을 보면 온프레미스 환경쪽에서 다이렉트로 퍼블릭으로 화살표가 되어있어서 좀 의문이 들었다. 저건 그냥 저렇게 연결 해도 되는건지..(물어보지는 못했다. ㅠㅠ)

그리고 통합 빌드나 이벤트 처리에 대해서도 위와같은 구성으로 진행을 할수 있게 되어있었다. 형상관리는 Git 이 될수도 있고 다른 툴이 될수도 있다. 소스 커밋이 되면 자동으로 빌드를 하고 그리고 Slack 같은 곳에 알림 서비스 까지 제공할수 있도록 할수 있다.  (제대로 이해한건지 잘 모르겠다. ㅡㅡ;)

 

Google Kubernetes Engine과 함께하는 인프라 현대화 - 조병욱, 구글 클라우드 Customer Engineer

분명 이 세션에서 많은 것을 들은것 같은데 그때문인지 과부화가 걸린것 같다. 그래서 기억 나는 부분만 설명하겠다.

우선 이건 배포에 대해서 설명하면서 나온 그림이었다. 같은 어플리케이션을 수십대에 동일한 서버에 배포를 한다고 가정을 해보자. 당연히 같은 어플리케이션이고 서버도 숫자만 많을뿐 동일한 설정이니 잘 배포가 될거라 생각이 된다. 하지만 여지없이 실패하고 만다. 그러면서 나온 패턴인데 vm 자체를 다 이미지로 구워서 배포를 하는 패턴이다. os 포함한 모든것을 다 굽기 때문에 그만큼 동일한 환경을 유지할 수 있다. 

 

그리고 Knative 에 대해서 설명을 해주셨는데 잘 기억이 안난다. (ㅠㅠ 망함..)

 

GCP에서 개인화된 쇼핑 경험 만들기 - 박경미, 구글 클라우드 Field Sales Representative

이 세션이 마지막 세션이었는데 그전에 다른 세션도 듣긴 했으나 기억이 나는 세션만 정리하다 보니 바로 이 세션이다. 

애널리틱스 트랙의 세션이었는데 Recommendations AI 에 대한 내용이 재미있었다. 

상품 구매시 추천 상품에 대한 내용인데 아래 사진을 보자. 

왼쪽은 기존에 가지고 있던 추천 시스템으로 테스트 한 결과이고 오른쪽은 Recommendations AI 를 학습시켜서 테스트한 결과이다. 저게 아마 블랙펜서 마스크였던것 같다. 사진을 보면 오른쪽에는 블랙펜서 장갑도 나오고 피규어들도 나오지만 왼쪽은 다른 것들이 나온다. 그래서 현재 Beta 이긴 하지만 적용을 한 업체에서는 만족을 하고 있다고 한다. 

그리고 발표자분께서 말씀하시길 유투브의 시청자들의 70%정도가 추천된 영상을 본다고 한다. 자신이 의도적으로 찾아서 본 영상이 아닌 내가 보고 있던 영상을 바탕으로 추천된 영상을 보는 비율이 70% 정도라고 하니 추천이 얼마나 중요한지 알수 있었다. 

 


오랜만에 갔던 세미나여서 인지 몸은 힘들었지만 머리는 맑아지는 느낌이 들었다. 요즘 공부하면서 약간은 지쳐가고 있었는데 다시 공부의 필요성을 느끼게 되서 나 자신에게도 다행이라고 생각되었다. 이제 갔다왔으니 다시 공부를 시작해야겠다. ^^;;;

 

728x90
반응형
반응형

ReplicaSet 은 Replicatation Controller 의 새로운 버전이다.

 

다른것은 다 동일한데 아래와 같은 차이점이 존재 한다.

 

ReplcaSet : Set-based Selectors

Replicatation Controller : Equality-based Selectors

 

  Equality-based  Set-based
support  Service, Replication Controller Job, Deployment, ReplicaSet, Daemon Set
Operation  =, ==, != in, notin, exists
Example  enviroment=prd enviroment in (prd)
Command Line kubectl get pods -l enviroment=prd kubectl get pods -l 'enviroment in (prd)'
Manifest selector: 
  enviroment: prd
selector:
 matchExpressions: 
   - {key: enviroment, operation: In, values: [prd]}

 

추가적으로 sectors 에 matchLabels 가 존재할 경우 아래와 같은 차이점이 있다.

Manifest

selector:
  app: nginx 

selector: 
  matchLabels: 
     app: nginx
support  Services, Replication Controller ReplicaSets, Deployments, Jobs, DaemonSet|

 

참고자료

https://www.youtube.com/watch?v=Y5ADo_tjfIs&list=PLMPZQTftRCS8Pp4wiiUruly5ODScvAwcQ&index=19

728x90
반응형
반응형

Kubernetes를 사용하면서 자주 사용하는게 kubectl 명령어 이다. 그리고 그중에서 컨테이너를 생성할때 항상 kubectl create 명령어를 사용했다. 그런데 사용하다보니 어떤 글에는 create 를 사용하고 어디에서는 apply 를 사용하는 것을 보게 되었다. 그래서 이 차이점이 궁금해서 이렇게 정리하게 되었다. 


아래 내용들은 kubernetes document 에서 요약한 내용들이다. 

https://kubernetes.io/docs/concepts/overview/object-management-kubectl/overview/



Kubernetes 에서 Object Management 에는 3가지가 있다. 


Management technique

Operates on

Recommended environment 

Supported writers 

 Imperative commands

 Live objects 

 Development 

 1+ 

 Imperative object configuration

 Individual files  

 Production 

 1 

 Declarative object configuration

 Directories of files 

 Production 

 1+ 



Imperative Commands


장점

- 클러스터에 특정 오브젝트를 한번에 실행하거나 시작할수 있는 가장 쉬운 방법이다. (실제 이미지 바로 실행 시킨다. )


단점

- 기존 설정에 대한 히스토리를 제공하지 않는다. (그래서 위에 권장 환경이 Development 인것 같다.)

- 변경사항이나 audit 내역, 템플릿등을 제공하지 않는다. 


ex)

kubectl run nginx --image nginx



Imperative object configuration


- 최소한 1개 이상의 YAML 이나 JSON 포맷의 파일을 이용해서 Object 를 생성한다. 


ex)

kubectl create -f nginx.yaml

Imperative object configuration vs Imperative Commands

장점

- 설정파일 내용을 Git 같은 곳에 저장이 가능하기 때문에 설정에 대한 변경 히스토리가 확인 가능하다. 

- 새로운 Object를 생성하기 위한 템플릿을 제공한다. 

단점

- YAML 파일 작성이 필요하며 템플릿 사용을 위해 Object schema 에 대해서 이해가 필요하다.


Imperative object configuration vs Declarative object configuration 

장점
- 더 간단하고 이해하기 쉽다.

단점

- 파일로 적용할때에만 동작한다. 디렉토리는 불가능.

- 실행중인 object 를 update 하기 위해서는 설정파일에 반영을 해야 한다. 



Declarative object configuration

- 모든 설정 파일들은 디렉토리 안에 들어있고 오브젝트를 생성하거나 패치 한다.


ex)

kubectl apply -f configs/


Declarative object configuration vs Imperative object configuration

장점

- 실행중인 오브젝트 직접 적용한 변경사항을 설정파일에 merge 하지 않더라도 유지된다.(???)


단점

- 디버깅 하기 어렵고 예상한 결과가 아닐 경우 이해하기 어렵다.

- diffs 를 사용한 부분 업데이트는 복잡한 병합과 패치를 만들게 된다.


Imperative commands 나  Imperative object configuration 는 이해가 되는데  Declarative object configuration 은 약간 이해가 안된다. 


https://kubernetes.io/docs/concepts/overview/object-management-kubectl/declarative-config/


여기 있는 샘플을 가지고 확인해보자.


sample_deployment.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
cs



Create : kubectl apply -f sample_deployment.yaml 

Live configuration : kubectl get -f sample_deployment.yaml -o yaml


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
kind: Deployment
metadata:
  annotations:
    # ...
    # This is the json representation of simple_deployment.yaml
    # It was written by kubectl apply when the object was created
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
  # ...
spec:
  # ...
  minReadySeconds: 5
cs


kubectl.kubernetes.io/last-applied-configuration 어노테이션에 보면 sample_deployment.yaml  에 적용한 내용들이 나와있다. 


다시 아래와 같이 명령어를 실행해보고 확인해보자.


kubectl scale deployment/nginx-deployment --replicas=2

Live configuration : kubectl get -f sample_deployment.yaml -o yaml


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # note that the annotation does not contain replicas
    # because it was not updated through apply
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
  # ...
spec:
  replicas: 2 # written by scale
  # ...
  minReadySeconds: 5
cs


이 경우에는 apply를 하지 않았기 때문에 kubectl.kubernetes.io/last-applied-configuration 어노테이션에 포함되지 않았다.


sample_deployment.yaml 파일을 수정해보자. 


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.11.9 # update the image
        ports:
        - containerPort: 80
cs


nginx image 버전이 1.7.9 에서 1.11.9 로 변경 되었다.


Create : kubectl apply -f sample_deployment.yaml 

Live configuration : kubectl get -f sample_deployment.yaml -o yaml


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # ...
    # The annotation contains the updated image to nginx 1.11.9,
    # but does not contain the updated replicas to 2
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment",
      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
      "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
      "spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx",
      "ports":[{"containerPort":80}]}]}}}}
    # ...
spec:
  replicas: 2 # Set by `kubectl scale`.  Ignored by `kubectl apply`.
  # minReadySeconds cleared by `kubectl apply`
  # ...
  selector:
    matchLabels:
      # ...
      app: nginx
  template:
    metadata:
      # ...
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.11.9 # Set by `kubectl apply`
cs


확인을 해보면 apply 로 적용한 nginx 버전은 kubectl.kubernetes.io/last-applied-configuration 어노테이션에 포함 되어있다. 하지만 replicas 는 포함되지 않았다.


Warning: Mixing kubectl apply with the imperative object configuration commands create and replace is not supported. This is because create and replace do not retain the kubectl.kubernetes.io/last-applied-configuration that kubectl apply uses to compute updates


그리고 위와 같은 주의 사항도 있다. apply 는 create 나 replace 를 지원하지 않는다는 거다. 이유는 create 나 replace 는 kubectl.kubernetes.io/last-applied-configuration 어노테이션을 유지 하지 않기 때문이라고 한다. 



apply 와 create 의 차이점을 찾아보다가 여기까지 오게 되었다. 결과적으로 가장 큰 차이점은 apply 를 할 경우에는 기존 설정에 대한 정보를 가지고 있다는 점인것 같다. 


apply 이외에도 다른 명령어들이 있지만 우선은 이것만 이해하는걸로 하자.





728x90
반응형

+ Recent posts