ParanBlog.

"Resources" - CPU, Memory, ...특징: 각 컨테이너에 대해 할당되는 값이다. 하나의 Pod에 여러 컨테이너가 있다면, 각각의 컨테이너는 다른 Resource Limit을 가진다.spec: containers: - name: asdf resources: requests: memory: "4Gi" cpu: 2 limits: memory: "8Gi" cpu: 4메모리야 4GiB라고 하지만 이 CPU 숫자는 무엇인가?CPU count1 CPU = 1 vCPU Core를 가리킨다 (SMT 시스템의 경우 1 SMT 쓰레드)0...

Taints, Tolerations특정 "Taint"가 씌워진 노드에는 Toleration이 없는 Pod가 배치될 수 없다강의에서는 "모기기피제를 뿌린 사람과 내성 없는 벌레"라는 비유를 쓴하지만, 만약 특정 Taint에 대한 Toleration이 있는 Pod라면 해당 Taint가 씌워진 노드에 배치될 수 있다.다만, 어떤 Pod이 특정 Taint에 대한 Toleration을 가지고 있다고 해서, Taint가 일치하는 노드에만 배치된다는 것은 아님스케줄러의 마음에 따라서는, 그냥 Taint 없는 다른 노드에 갈 수도 있음이것은 "특정 노드가 어떤 Pod을 받아들일것인가"에 대한 문제이기 때문에, "특정 Pod을 어떤 노드에 지정하고 싶다"라는 경우 Node Selector를 이용하여야 함즉 Taint는 ..

Imperative어떠한 목표를 달성하기 위한 자세한 instruction을 작성함(중간에 절차가 멈추고 뻗는다든가 했을 때에 resume하기가 귀찮아진다)'web-server'라는 이름으로 VM 생성Nginx 설치Nginx 설정파일 변경: 포트 8080 사용Nginx 설정파일 변경: 웹 경로 /var/www/nginx 사용Git Repo X에서 /var/www/nginx 경로에 pullnginx 시작Kubernetes에서의 imperative way장점:시험 볼 때같이 간단한 환경을 잠깐 쓸 때에는 좋음단점: 특정 Session에서 실행했을 때 해당 Session에서만 유효함.기능이 제약되어 있음 (multi-container pod deployment 등은 불가)Imperative command 이용..

지금까지는 Default 네임서페이스를 사용하고있었다.쿠버 내부에서 사용하는 Pod, Service에 대해서는, (DNS, 네트워킹 등) kube-system 네임서비스를 사용한다모든 사용자들이 사용할 수 있는 리소스는 kube-public으로 지정된다클러스터가 작으면 default 네임스페이스로 상관없지만, 엔터프라이즈/프로덕션 환경에서는 namespace로 나눠 쓰는 편이 좋다예를 들어, 개발환경과 프로덕션환경에서 똑같은 클러스터를 사용하면서도 리소스는 isolate하고 싶은 경우, Dev와 Prod 네임스페이스를 따로 만들어 사용할수있을것이다각네임스페이스는 누가 무엇을 할 수 있는지에 대한 정책을 가지고있다네임스페이스별로 최대사용가능 리소스 리밋을 걸 수 있다각각의 네임스페이스 구성원들끼리는 그냥 ..

앱 외부와 내부의 컴포넌트 간의 연결을 가능하게 함프론트와 백엔드 Pod group 간의 연결end user와의 연결 DB와의 연결서비스란, 노드상에 떠 있는 일종의 가상-서버같은 역할을 한다192.168.1.2라는 IP를 가진 Node 위에 있는 Pod의 네트워크 범위가 10.244.0.0/24 라고 하고, Pod의 IP가 10.0.244.2라고 하자.NodePortNodePort 서비스는 노드에서 외부 IP로 들어오는 특정 포트에 대해 listen하고 있다가, 해당 포트로 들어오는 연결을 Pod의 포트로 포워딩하는 역할을 한다.TargetPort: Pod에서 Listen하고 있는 포트Port: NodePort 서비스의 포트ClusterIP: NodePort 서비스의 내부 IPNodePort: 실제 노..

ReplicationController는 구세대 기술로 ReplicaSet으로 대체되고있다ReplicationControllerReplicationController/ReplicaSet은 쿠버네티스 클러스터 상에서 하나의 Pod에 대한 인스턴스 여려 개를 구동할 수 있게 하여 HA(High Availability)를 제공하나의 Pod만 존재하는 상황에서도 ReplicationController는 Pod 하나가 죽더라도 자동으로 Pod를 새로 만들어주므로, 쓸모가 있음단일 ReplicationController 아래에 여러 노드의 Pod이 있을 수 있음apiVersion: v1kind: ReplicationControllermetadata: name: myapp-rc labels: app: mya..

쿠버의 Object를 생성하기 위한 YAML은, Pod, Deployment, Service, ReplicaSet, 뭐든 상관없이 대강 아래처럼 생겼으며, 아래의 3가지 root level properties를 꼭 가져야한다.apiVersion: v1kind: Podmetadata: name: myapp-pod labels: app: myapp type: frontendspec: containers: - name: nginx-container # -는 YAML에서 리스트의 첫 항목임을 가리킴 image: nginx - name: busybox image: busyboxapiVersion / kindPod, Service: v1ReplicaSet, Deployment: ap..

kube-apiserverAPI 요청을 authenticate하고, 검증하고, etcd 클러스터에서 데이터를 뽑아서 전달한다etcd와 상호작용하는 유일한 컴포넌트시스템 컴포넌트들의 상태를 주기적으로 확인하고, 문제가 있을 경우 해결을 시도한다다양한 컴포넌트를 체크하는 Controller들이 kube-controller-manager에 올인원으로 들어가 있다kube-controller-manager예 - Node Controller의 경우:5초에 한 번씩 kube-apiserver를 통해 워커노드의 kubelet을 호출, 상황을 확인함노드에서 heartbeat가 오지 않는 경우 40초 후에 unreachable 처리5분 후에도 복구되지 않은 경우 해당 노드에 할당된 Pod을 제거예 - Replication..