CKA

Cluster Architecture kubernetes의 목적은 개발자의 application을 하나의 container로 만들어서 배포하고, 통신하도록 하는 것이 주된 목적이다. kubernetes는 container들을 컨트롤하는 역할을 해주는데, 다음과 같다.

Pod kubernetes에서는 container를 container로만 올리지않고, pod안에 감싸서 배포한다. pod가 바로 kuberntes cluster를 이루는 가장 중요한 요소가 되는 것이다. 사용자가 많아지면 pod를 늘리고, 사용자가 적어지면 pod를

Controller는 kubernetes의 object를 모니터링하고 원하는 state로의 동작을 진행한다. node에 하나의 pod가 다운되는 것은 당연하다고 생각하면 된다. 그렇기 때문에 여러 개의 pod를 배포하고 자동 복구할 수 있도록 해야하는데, 이를 가능하게

kubernetes service는 app들이 cluster내부, 외부에서의 통신을 가능하게 해준다. 즉, cluster 내부의 pod들끼리의 통신이 가능하게 주고, 동시에 cluster 외부인 user와 외부 cluster 또는 data source에 연결하여 통신이

kubernetes object를 생성하고 설정하는 방식에는 두 가지 방식이 있는데, 하나는 imperative(명령적) 방식과 하나는 Declarative(선언적) 방식이다.imperative는 좌회전, 우회전, 직진과 같이 매번의 course마다 관리자가 clust

kubernetes의 default scheduler를 통해서 스케줄링을 받지 않고, 직접 pod의 scheduling을 설정하고 싶으면 어떻게해야할까??pod-definition.yaml위의 pod정의에서 사실 nodeName이라는 field가 있다.nodeName는

label은 kubernetes object를 특정 기준으로 묶어 여러 group으로 만드는 방법 중 하나이다. selector는 이러한 label을 기준으로 특정 kubernetes object group을 선택해 policy를 적용하는 방법이다.label들은 key

taints와 tolerations는 pod를 어떤 node에 스케줄링한 것인지에 대한 개념이다. taints는 node에 적용하고 tolerations은 pod에 적용하는 field라고 생각하면된다.다음과 같이 pod 3개가 있고, node 3개가 있다고 하자. po

node selector와 node affinity 둘 다 pod를 특정 node로 지정하여 스케줄링하는 방법에 대한 것들이다. 먼저 node selector에 대해서 알아보도록 하자.다음의 pod들과 node들이 있다고 하자. 이들은 서로 자원량이 다르기 때문에 크기

pod에는 필요로 하는 cpu, memory 자원량이 있는데, 현재 node의 자원 현황을 토대로 이 pod들을 배치시켜주는 것이 kubernetes scheduler의 몫이다.가령 다음과 같은 예를 보도록 하자.다음의 상황에서 pod들은 node에 할당될 때, 다음과

DaemonSet은 Deployment와 비슷하게 pod를 관리하지만, 재밌게도 node마다 pod를 관리한다는 것이다. 가령, DaemonSet을 하나 만들어서 node마다 하나의 pod를 만들라고하면, node마다 하나의 pod씩이 만들어지고 DaemonSet이 이

kubelet은 worker node에서 독립적으로 container를 구동할 수 있다. 즉, master node의 kube-apiserver, etcd 등과 연결이 안되었을 때에도 pod를 만들 수 있다는 것이다. kubelet만으로 worker node에서 mas

kubernetes cluster를 운영하다보면 pod의 memory, cpu 사용량, node의 총 갯수, 전체 cluster에서 사용하고 있는 자원량 등 다양한 metric이 필요할 때가 있다.이러한 metric정보들을 관리하여 cluster 정보를 사용자에게 제공

Deployment에서는 pod에 대한 replicas를 관리하여, 재시작, versioning 등을 제공한다고 하였다. 여기서 versioning으로 pod의 version을 올리고 내릴 수 있는데, rollout이 바로 version을 올리는 작업을 말하고, rol

시험을 위해 명령어들을 정리해보도록 하자.container는 vm과 달리 os를 구동하는 것이 아니라, os에서 특정 task를 구동하는 것이다. 따라서, 다음과 같이 os만 구동하는 경우 바로 container가 내려가게 된다.그래서 Dockerfile내부를 보면 C

docker에서 환경변수를 전달할 때는 다음과 같이 전달할 수 있다.pod역시도 마찬가지인데, 다음과 같다.pod-definition.yamlsimple-webapp-color container의 환경변수로 APP_COLOR key로 pink value가 들어가는 것이

보통 Microservice구조에서 app이 두 개 있다면 pod를 두 개로 만드는 것이 일반적인 시스템이다.그런데, 특정한 경우 pod안에 두 개의 container를 만들어 배포해야할 때가 있는데, 가령 다음과 같다.하나의 pod에 main이 되는 app은 web

만약 특정 node의 os를 upgrade하는 등의 일을 위해서, 해당 node를 reboot해야하는 상황이 발생한다고 하자.이때에는 해당 node의 pod들이 다운될 수 밖에 없는데, 만약 5분이 지나도 node가 복구되지 않으면, 이후에 node가 복구되어도 해당

kubernetes cluster에 배포되어 있는 pod, service, deployment 등등의 kubernetes resource들을 backup하여 저장하고 싶다면 어떻게해야할까?? 이 경우 kube-apiserver에 resource configuration

kubernetes cluster의 보안에 있어서 가장 핵심이 되어야하는 곳은 바로 kubernetes api server이다. kubernetes api server는 user로부터 요청을 받아 cluster의 object들을 제어하고 관리해주며, cluster에 필

kubeconfig는 kubectl cli를 설정하는 configuration 파일으로, 어떤 kube-apiserver에 어떤 ca, cert 파일을 토대로 상호작용할 것인지를 설정할 수 있다.가령, my-kube-playground:6443에 요청을 보낸다고 할 때

kube apiserver는 여러 그룹화된 API들이 존재하는데, 다음과 같이 나눌 수 있다.1\. /metrics2\. /healthz3\. /version4\. /api5\. /apis6\. /logsapi와 apis가 헷갈릴 수 있는데, core api와 name

kubernetes에서는 두 가지 계정 개념을 통해 '인증'을 처리한다. 참고로 이전에 배운 Role, RoleBinding의 경우는 '권한'에 관한 문제로, '인증'조차 되지 않으면 kubernetes API에 접근 조차 불가능하므로 '인증'이 먼저되어야 한다.use

pod스펙에서 image: nginx라고 쓰여있다면, 다음과 같이 image 네이밍 부분을 쪼갤 수 있다.docker에서 image이름 앞에 아무것도 없다면 이는 user account가 명시되지 않아 default값인 library로 설정된다. 따라서 library/

client-server구조에서 client가 web server에 요청을 보내어 traffic이 server안으로 들어오는 것을 ingress라고 한다.반대로 server에서 client로 요청을 보내는 traffic을 egress라고 한다.kubernetes clu

docker storage 개념은 두 나뉘어져 있는데, 하나는 storage drivers이고 하나는 volume drivers이다.우리는 먼저 storage drivers에 대해서 알아보고, volume drievers를 알아보도록 하자.docker가 설치되면 /va

서로 다른 host들은 ethernet 네트워크에 연결을 위해 각자의 network interface 카드(NIC)를 사용한다. 이 NIC는 스위치에 연결되어 같은 네트워크를 이루는 것이다.자신의 ethernet을 보기위해서는 ip link를 쓰면 된다.switch가

network namespace는 docker와 같은 container에서 host의 network를 나누기 위해서 사용한다.container를 만들면, 각 container들끼리 격리되기를 원할 것이다. 즉, container에 동작하는 process는 다른, con

dokcer의 network에 대해서 알아보도록 하자. 먼저 docker engine이 설치된 host가 다음과 같이 있다고 하자.다음과 같이 host의 network interface가 eth0으로 '192.168.1.10'을 가지고 있다고 하자.이제 containe

이전까지 linux에서 network namespace를 만들고, 설정하는 방법과 docker에서 network namespace를 만들어 container에 할당하고 network를 구성하는 방법에 대해서 배웠다. docker container가 만들어지고 netwo

기본적으로 어떻게 하나의 node에서 kubernetes component들이 네트워킹을 이루고, 연결이 되었는 지를 알게되었었다. 그런데, 서로 다른 node에 있는 pod들끼리는 어떻게 네트워크를 이루고 소통이 가능한 것일까??어떻게 서로 다른 node에 배포된 p

그럼 이제 서로 다른 node에 있는 pod들끼리 어떻게 통신을 할 수 있는 지 알아보도록 하자.pod들끼리는 각자의 IP를 통해서 서로 통신이 가능하지만, pod가 죽었다 살아나면 IP가 바뀐다. 따라서, pod의 IP를 통한 통신은 지속적으로 좋지 않은 방법이다.

많은 사람들이 헷갈려하는 것 중 하나가 service와 ingress이다. Ingress는 kubernetes object로서 layer 7에 해당하는 network 기능을 제공해준다. 가령 TLS를 통한 https제공, host name기반의 라우팅, path기반의

etcd는 분산 신뢰기반 key-value 저장소로 빠르고 안전한 데이터 접근을 제공한다. 그런데, '분산'이라는 것이 무엇일까?? 다음을 보도록 하자.etcd의 idea는 다음과 같다.다음과 같이 3개의 etcd server가 존재하고, 이들은 data를 모두 동일하

만약 kubernetes control plane component들이 kubeadm으로 설치되었다면, kubectl 명령어로 접근이 가능하다. 반면에, service로 배포되었다면 다음의 명령어로 상태를 확인할 수 있다.control planeworker nodelo

yaml은 json, xml과 같이 config data를 표현하기 위한 하나의 형식이다.key value pairarray/listDictionary/Mapindentation에 있는 것을 조심하자. indentation이 다르면 상하 계층관계를 나누기 때문이다. 여

kubernetes에서 jsonpath를 사용하여 여러 유용한 query가 가능하다.사실 kubectl이 명령을 받아서, kube-apiserver에 요청을 보내면 json 형식으로 응답을 받는다. 이 데이터를 사용자에게 보기 좋게 컨버팅해서 전달해주는 것이 전부이다.

kubeadm을 통해 v1.29.0에서 v1.30.0으로 업그레이드해라, 단, 각 node를 업그레이드 하기 전에 gold-nginx deployment가 먼저 다른 node로 재스케줄 되어야 한다.https://kubernetes.io/docs/setup/p

nginx:alpine image를 사용하는 nginx-pod를 배포하도록 하자.redis:alpine image를 사용하는 messagin pod 배포하되, label로 tier=msg를 설정하도록 하자.apx-x9984574 namespace를 만들도록 하자.nod

etcd backup을 하여 /opt/etcd-backup.db에 저장하도록 하자.etcd config 확인redis:alpine image를 가진 redis-storage라는 pod를 생성하고, volume으로는 emptyDir를 가지고도록 한다.pod이름은 redi

pvviewer라는 새로운 service account를 만들고, pvviewer-role-binding이라는 cluster role을 만들어서 pv에 대한 list권한을 주도록 하자. 또한, pvviewer-role-binding이라는 ClusterRoleBindin

사실 지난 2년간 kubernetes 환경에서 개발도 했고, helm chart들도 직접 만지면서 꽤나 익숙한 상태였다. 딱히 CKA를 볼 마음은 없었지만, 회사에서 무언의 압박(아마 매니저분들의 실적에 들어가나보다)이 계속되었고, 지난 8월에 뭄샤드 인도 강의를 보게