내 작은 개발 이야기

pod의 status가 pending 상태일 때, pending인 이유를 찾으세요 나의 답안 ) kubectl describe po 를 했을 때 정보가 출력되었지만 pending인 이유까지 유추하지 못함 Solution ) kubectl describe po 를 했을 때 Node 필드가 임. 이로 미루어보아 스케쥴러가 적합한 노드에 파드를 스케쥴링하지 못함 kubectl get po -n=kube-system 출력된 kube-system 네임스페이스의 파드 중, 스케쥴러가 없는것을 확인함 즉, pending이 되는 이유는 스케쥴러가 없기때문이다. nginx Pod를 node01에 스케쥴링 하세요 나의 답안 ) nginx Pod Manifest에서 spec.nodeName 필드 추가, nodeName: n..

Pod를 만드세요name = redisimage = redis:alpinelabels = "tier=db"나의 답안) kubectl run redis --image=redis:alpine --dry-run=client -o yaml > ./redis.yaml vim redis.yaml 후 labels 아래에 tier=db 추가 kubectl apply -f redis.yaml Solution ) kubectl run redis --image=redis-alpine --labels="tier=db" svc를 만드세요name = redis-serviceport = 6379나의 답안) kubectl create svc redis-service --tcp=6379:6379 --dry-run=client -o y..

여러 네임스페이스 중, "blue"라는 이름을 가진 파드가 있는 네임스페이스를 찾으세요 나의 답안)kubectl get po --selector name=blue --all-namespaces -o wide Solution )나의 답안과 거의 일치, 그러나 --all-namespaces 옵션은 -A (대문자)로 바꿀 수 있다kubectl get po -A 다른 네임스페이스의 svc에 접근 시 DNS ex) dev 네임스페이스의 svc db-service에 연결할 때의 도메인은 db-service.svc.cluster.local 이 된다.

NameSpace Manifest 작성 예시 ( kubectl apply -f )apiVersion: v1kind: Namespacemetadata: name: dev 명령어로 생성kubectl create namespace dev Pod Manifest에 NameSpace 작성 예시apiVersion: v1kind: Podmetadata: name: nginx #metadata 아래에 작성한다 namespace: dev labels: - app: nginx tier: nginxspec: containers: - name: nginx-container image: nginx 특정 NameSpace에 있는 파드 조회kubectl get po --namespace=kubectl g..

Kubernetes Service 리소스의 spec.type 필드는 네트워크 트래픽을 처리하는 방식에 따라 서비스의 노출 유형을 지정하는 데 사용됩니다. spec.type에는 다음과 같은 값들이 들어갈 수 있습니다:1. ClusterIP기본값: spec.type을 지정하지 않으면 기본적으로 ClusterIP가 사용됩니다.설명: 클러스터 내부 IP(ClusterIP)를 통해 서비스에 접근할 수 있게 합니다. 외부에서 접근할 수 없으며, 클러스터 내 다른 파드에서만 접근 가능합니다.사용 사례: 클러스터 내부 통신 전용 서비스가 필요한 경우, 예를 들어 내부 마이크로서비스 간 통신.apiVersion: v1kind: Servicemetadata: name: my-internal-servicespec: ty..

ex) pod.yamlapiVersion: v1kind: Podmetadata: name: nginx labels: app: nginx tier: nginxspec: containers: - name: nginx-container image: nginx ex) service.yamlapiVersion: v1kind: Servicemetadata: name: nginx-servicespec: type: NodePort ports: #Service로 들어온 요청을 라우팅할 포트 - targetPort: 8080 #클러스터 내에서 접근 가능한 포트 port: 80 #일반적으로 30000-32767, 클러스터 외부에서 접근 가능한 포트 NodePo..

Kubernetes의 Service 리소스에서 port, targetPort, nodePort는 서비스가 요청을 받아서 파드로 전달하는 과정을 제어하는 주요 필드입니다. 각 필드는 다른 네트워크 계층에서의 포트 역할을 의미합니다.1. port역할: 클러스터 내부에서 Service가 사용할 포트입니다.위치: 클러스터의 가상 IP(ClusterIP)에서 바인딩됩니다.설명:서비스가 트래픽을 받는 포트로, 클러스터 내의 다른 파드가 이 서비스에 접근할 때 사용하는 포트입니다.예를 들어, Service의 ClusterIP가 10.0.0.5이고 port가 80이라면, 10.0.0.5:80을 통해 서비스에 요청을 보낼 수 있습니다.2. targetPort역할: Service가 연결할 파드 내 컨테이너의 포트입니다.위..

ReplicationController vs ReplicaSet ReplicationController yaml 예시 apiVersion: v1kind: ReplicationControllermetadata: name: myapp-rc labels: app: myapp tier: frontendspec: template: metadata: name: myapp tier: frontend spec: containers: - name: myapp-container image: nginx replicas: 3kubectl get replicationcontroller ReplicaSet yaml 예시 apiVersion: apps/v..

nginx 이미지로 Pod를 만드는 예제 나의 답안 ) vi 편집기로 nginx.yaml을 만들어서 실행 apiVersion: v1kind: Podmetadata: name: nginx metadata: app: nginx tier: frontendspec: containers: - name: nginx image: nginxkubectl apply -f nginx.yaml Solution ) kubectl run nginx --image=nginx Pod가 실행중인 Node는 어디인가요? 나의 답안 ) kubectl describe po  Solution ) kubectl get po -o wide -> header Node에서 확인 name=redis image=redis123..

Kubernetes에서 kube-proxy는 네트워크 통신을 관리하고, 클러스터 내에서 서비스와 Pod 간의 트래픽을 효율적으로 라우팅하는 역할을 담당합니다. Kubernetes는 각 노드에서 실행되는 여러 Pod들 간의 통신을 원활하게 하기 위해서, kube-proxy를 사용하여 네트워크 규칙을 설정하고, 외부에서 클러스터로 들어오는 트래픽과 클러스터 내에서의 트래픽을 처리합니다.1. kube-proxy의 역할kube-proxy의 주요 역할은 Kubernetes 서비스와 관련된 네트워크 규칙을 설정하고, 그에 따라 Pod 간의 트래픽 라우팅을 관리하는 것입니다. 구체적으로는:Pod 간의 통신 지원: 같은 클러스터 내에 있는 서로 다른 노드의 Pod들이 통신할 수 있도록 네트워크 경로를 설정하고 관리합니..