KubernetesINACTION/밑줄긋기 - Revision history

Maintenance script: Repair batch-0002 pages from live compare

2026-03-27T00:16:06Z

Repair batch-0002 pages from live compare

← Older revision		Revision as of 00:16, 27 March 2026
Line 1:		Line 1:
	~~[[pagelist~~(^KubernetesINACTION)~~]]~~		<!-- MONIWIKI PageList(^KubernetesINACTION) -->
			* [[KubernetesINACTION/밑줄긋기]]
			* [[KubernetesINACTION/밑줄긋기/스터디]]
	__TOC__		__TOC__
	== 쿠버네티스 소개 ==		== 쿠버네티스 소개 ==
Line 94:		Line 96:
	FROM node:7		FROM node:7
	ADD app.js /app.js		ADD app.js /app.js
	ENTRYPOINT ["node", "app.js"]		ENTRYPOINT ["node", "app.js"]
	* Dockerfile을 쓴지 오래되긴 했다. - [[김준석]]		* Dockerfile을 쓴지 오래되긴 했다. - [[김준석]]
	* p79		* p79
Line 454:		Line 456:
	** DNS를 통한 서비스 검색		** DNS를 통한 서비스 검색
	** FQDN을 통한 서비스 연결		** FQDN을 통한 서비스 연결
	** 서비스명.네임스페이스.svc.cluster.~~local[[0~~-9]]* 이었던가.. 여튼 DNS / FQDN을 쓰진 않지만 동작은 같은걸로 앎. DNS에서 가져오고 FQDN으로 서비스명 매치 - [[김준석]]		** 서비스명.네임스페이스.svc.cluster.local0-9* 이었던가.. 여튼 DNS / FQDN을 쓰진 않지만 동작은 같은걸로 앎. DNS에서 가져오고 FQDN으로 서비스명 매치 - [[김준석]]
	=== 클러스터 외부에 있는 서비스 연결 ===		=== 클러스터 외부에 있는 서비스 연결 ===
	* p221		* p221
Line 714:		Line 716:
	** 두명령어는 두 가지 서로 다른 형식을 지원한다.		** 두명령어는 두 가지 서로 다른 형식을 지원한다.
	*** shell형식 - 예: ENTRYPOINT node app.js		*** shell형식 - 예: ENTRYPOINT node app.js
	*** exec 형식 - 예: ENTRYPOINT [[:node , "app.js"]]		*** exec 형식 - 예: ENTRYPOINT :node , "app.js"
	*** exec 형식을 사용하면 셸 내부가 아니라 컨테이너 내부에서 프로세스를 직접 실행한다는게 무슨 의미지 - [[서지혜]]		*** exec 형식을 사용하면 셸 내부가 아니라 컨테이너 내부에서 프로세스를 직접 실행한다는게 무슨 의미지 - [[서지혜]]
	**		**
Line 745:		Line 747:
	* p314		* p314
	** 애플리케이션이 자바로 작성된 경우에는 System.getenv("INTERVAL"). NodeJS로 작성도니 경우에는 process.env.INTERVAL, 파이썬으로 작성된 경우네는		** 애플리케이션이 자바로 작성된 경우에는 System.getenv("INTERVAL"). NodeJS로 작성도니 경우에는 process.env.INTERVAL, 파이썬으로 작성된 경우네는
	os.environ.['INTERVAL']을		os.environ.['INTERVAL']을
	사용하면 된다.		사용하면 된다.
	** 기본 env 호출법 밑줄 - [[김준석]]		** 기본 env 호출법 밑줄 - [[김준석]]
Line 796:		Line 798:
	* p325		* p325
	**		**
	args: ["$(INTERVAL)"]		args: ["$(INTERVAL)"]
	** 앞에서 한 것과 동일하게 환경변수를 정의했지만 $(ENVVARIABLENAME) 문법을 사용해 쿠버네티스가 해당 변수의 값을 인자에 주입한다.		** 앞에서 한 것과 동일하게 환경변수를 정의했지만 $(ENVVARIABLENAME) 문법을 사용해 쿠버네티스가 해당 변수의 값을 인자에 주입한다.
	** 정의 밑줄 - [[김준석]]		** 정의 밑줄 - [[김준석]]
Line 970:		Line 972:
	**		**
	$ kubectl proxy		$ kubectl proxy
	and ~~{{{~~$ curl localhost:8001~~}}}~~		and $ curl localhost:8001
	** kube-proxy에 접근 - [[김준석]]		** kube-proxy에 접근 - [[김준석]]
	** 초기 버전의 쿠버네티스에 도입된 가장 일반적인 리소스 유형들은 특정 그룹에 속하지 않는다. APi 그룹은 나중에 도입됐다. API 그룹이 없는, 이런 초기 리소스 유형은 이제 core API 그룹에 속하는 것으로 간주된다.		** 초기 버전의 쿠버네티스에 도입된 가장 일반적인 리소스 유형들은 특정 그룹에 속하지 않는다. APi 그룹은 나중에 도입됐다. API 그룹이 없는, 이런 초기 리소스 유형은 이제 core API 그룹에 속하는 것으로 간주된다.
Line 1,507:		Line 1,509:
	securityContext:		securityContext:
	fsGroup: 555		fsGroup: 555
	supplementalGroups: [666, 777]		supplementalGroups: [666, 777]
	=== 파드의 보안 관련 기능 사용 제한 ===		=== 파드의 보안 관련 기능 사용 제한 ===
	* p587		* p587

Maintenance script: Repair MoniWiki formatting after migration

2026-03-26T14:01:39Z

Repair MoniWiki formatting after migration

← Older revision		Revision as of 14:01, 26 March 2026
Line 1,827:		Line 1,827:
	** 노드에 테인트를 추가하는 것만으로도 파드가 특정 노드에 배포되지 않도록 한다. 테인트된 노드에 배포할 파드는 테인트된 노드를 사용하게 선택할 필요가 있는 반면, 노드 셀렉터를 사용하면 파드를 배포할 노드를 명시적으로 지정한다.		** 노드에 테인트를 추가하는 것만으로도 파드가 특정 노드에 배포되지 않도록 한다. 테인트된 노드에 배포할 파드는 테인트된 노드를 사용하게 선택할 필요가 있는 반면, 노드 셀렉터를 사용하면 파드를 배포할 노드를 명시적으로 지정한다.
	* p685		* p685
	** 마스터 노드에는 테인트가 하나 있따. 테인트에는 키, 값, 효과 가 있고 ~~<~~key~~>~~=~~<~~value~~>~~:~~<~~effect~~>~~ 형태로 표시된다.		** 마스터 노드에는 테인트가 하나 있따. 테인트에는 키, 값, 효과 가 있고 <key>=<value>:<effect> 형태로 표시된다.
	**		**
	node-role.kubernetes.io/master <key> null <value> 효과는 NoSchedule		node-role.kubernetes.io/master <key> null <value> 효과는 NoSchedule
Line 1,982:		Line 1,982:
	== 애플리케이션 개발을 위한 모범 사례 ==		== 애플리케이션 개발을 위한 모범 사례 ==
	== 쿠버네티스의 확장 ==		== 쿠버네티스의 확장 ==

110.8.62.99 at 16:00, 18 May 2022

2022-05-18T16:00:26Z

← Older revision		Revision as of 16:00, 18 May 2022
Line 141:		Line 141:
	=== 쿠버네티스에 첫 번째 애플리케이션 실행하기 ===		=== 쿠버네티스에 첫 번째 애플리케이션 실행하기 ===
	* p97		* p97
	** 쿠버네티스는 개별 컨테이너들을 직접 다루지 않는다. 대신 함꼐 배치된 다수의 컨테이너라는 개념을 사용한다. 이 컨테이너의 그룹의 이름을 파드라고 한다.		** 쿠버네티스는 개별 컨테이너들을 직접 다루지 않는다. 대신 함께 배치된 다수의 컨테이너라는 개념을 사용한다. 이 컨테이너의 그룹의 이름을 파드라고 한다.
	** POD는 여러개의 컨테이너가 들어갈수 있음. - [[김준석]]		** POD는 여러개의 컨테이너가 들어갈수 있음. - [[김준석]]
	** 각 파드는 자체 IP, 호스트 이름, 프로세스 등이 있는 논리적으로 분리된 머신이다.		** 각 파드는 자체 IP, 호스트 이름, 프로세스 등이 있는 논리적으로 분리된 머신이다.
Line 159:		Line 159:
	*** 외부에서 Traffic 받을려면 가장 simple한 방법이라... 오히려 node port 방식이 더 드물긴 합니다. - [bluemir]		*** 외부에서 Traffic 받을려면 가장 simple한 방법이라... 오히려 node port 방식이 더 드물긴 합니다. - [bluemir]
	* p101		* p101
	**		** ` kubectl expose rc kubia --type= LoadBalancer --name kubia-http `
	kubectl expose rc kubia --type=LoadBalancer --name kubia-http		** ` kubernetes 서비스에 관한 설명은 생략 `
	**
	kubernetes 서비스에 관한 설명은 생략
	* p103		* p103
	** kubectl run 명령을 수행하면 레플리케이션컨트롤러를 생성하고 레플리케이션컨트롤러가 실제 파드를 생성한다.		** kubectl run 명령을 수행하면 레플리케이션컨트롤러를 생성하고 레플리케이션컨트롤러가 실제 파드를 생성한다.
Line 172:		Line 170:
	** 새로운 파드는 다른 IP 주소를 할당받는다. 이것이 바로 서비스가 필요한 이유다.		** 새로운 파드는 다른 IP 주소를 할당받는다. 이것이 바로 서비스가 필요한 이유다.
	* p106		* p106
	**		** ` kubectl scale rc kubia --replicas=3 `
	kubectl scale rc kubia --replicas=3		** ` kubectl get rc `
	**
	kubectl get rc

	* p107		* p107
	** 서비스는 다수 파드 앞에서 로드밸런서 역할을 한다. 파드가 하나만 있으면 서비스는 이 파드 하나에 정적 주소를 제공한다.		** 서비스는 다수 파드 앞에서 로드밸런서 역할을 한다. 파드가 하나만 있으면 서비스는 이 파드 하나에 정적 주소를 제공한다.

	* p109		* p109
	** 어떤 노드에 파드가 스케줄링됐는지 궁금할 수 있다. 쿠버네티스에서는 파드가 적절히 실행하는 데 필요한 CPU와 메모리를 제공하는 노드에 스케줄링됐다면, 어떤 노드에 파드가 실행 중인지는 중요하지 않다.		** 어떤 노드에 파드가 스케줄링됐는지 궁금할 수 있다. 쿠버네티스에서는 파드가 적절히 실행하는 데 필요한 CPU와 메모리를 제공하는 노드에 스케줄링됐다면, 어떤 노드에 파드가 실행 중인지는 중요하지 않다.
Line 186:		Line 180:
	* p110		* p110
	** 쿠버네티스 또한 꽤 멋진 웹 대시보드를 함께 제공한다는 점을 알게 되면 기뻐할 것이다.		** 쿠버네티스 또한 꽤 멋진 웹 대시보드를 함께 제공한다는 점을 알게 되면 기뻐할 것이다.
	*** 실제로 하드하게 써보면 별로 안기쁘더라구요 - [bluemir]		** 실제로 하드하게 써보면 별로 안기쁘더라구요 - [bluemir]
	== 파드: 쿠버네티스에서 컨테이너 실행 ==		== 파드: 쿠버네티스에서 컨테이너 실행 ==
	=== 파드 소개 ===		=== 파드 소개 ===

imported>bluemir at 03:12, 29 December 2021

2021-12-29T03:12:40Z

← Older revision		Revision as of 03:12, 29 December 2021
Line 1,802:		Line 1,802:
	* 모든 노드가 한계에 도달해 더 이상 파드를 추가할 수 없을 때는 어떻게 될까?		* 모든 노드가 한계에 도달해 더 이상 파드를 추가할 수 없을 때는 어떻게 될까?
	* 쿠버네티스는 추가적인 노드가 필요한 것을 탐지하면 가능한 빠르게 추가 노드를 클라우드 제공자에게 요청하는 기능을 가지고 있다.		* 쿠버네티스는 추가적인 노드가 필요한 것을 탐지하면 가능한 빠르게 추가 노드를 클라우드 제공자에게 요청하는 기능을 가지고 있다.
			*** 실제로는 `cloud provider`라는 componemet 에게 위임합니다. 잘 알려진 제공자(GCP, AWS)가 아닌경우 cloud provider 를 직접 구현해야 해요 - [bluemir]
	* 새 파드가 생성된 후 스케줄러가 기존 노드에 스케줄링할 수 없는 경우, 새로운 노드가 공급된다. 클러스터 오토스케일러는 이런 파드를 찾고 클라우드 제공자에 추가 노드를 시작하도록 요청한다.		* 새 파드가 생성된 후 스케줄러가 기존 노드에 스케줄링할 수 없는 경우, 새로운 노드가 공급된다. 클러스터 오토스케일러는 이런 파드를 찾고 클라우드 제공자에 추가 노드를 시작하도록 요청한다.
	* 클러스터 오토스케일러는 사용 가능한 노드 그룹을 검사해 최소한 하나의 노드 유형이 스케줄링되지 않은 파드를 수용할 수 있는지 확인한다.		* 클러스터 오토스케일러는 사용 가능한 노드 그룹을 검사해 최소한 하나의 노드 유형이 스케줄링되지 않은 파드를 수용할 수 있는지 확인한다.

imported>bluemir at 03:11, 29 December 2021

2021-12-29T03:11:01Z

← Older revision		Revision as of 03:11, 29 December 2021
Line 1,815:		Line 1,815:
	$ kubectl drain <node> // 명령은 노드를 스케줄링 할 수 없음으로 표시하고 노드에서 실행 중인 모든 파드를 종료한다.		$ kubectl drain <node> // 명령은 노드를 스케줄링 할 수 없음으로 표시하고 노드에서 실행 중인 모든 파드를 종료한다.
	** 데몬셋은 이거 무시하고 실행하던데...? - [[김준석]]		** 데몬셋은 이거 무시하고 실행하던데...? - [[김준석]]
			** 데몬셋은 모든 node에서 실행되니 Drain 하더라도 의미가 없어서 그렇습니다. - [bluemir]
	* 클러스터 오토스케일러는 다음 클라우드 제공자에서 사용할 수 있다.		* 클러스터 오토스케일러는 다음 클라우드 제공자에서 사용할 수 있다.
	** 구글 쿠버네티스 엔진		** 구글 쿠버네티스 엔진

imported>bluemir at 03:10, 29 December 2021

2021-12-29T03:10:18Z

← Older revision		Revision as of 03:10, 29 December 2021
Line 1,823:		Line 1,823:
	*특정 서비스에서는 최소 개수의 파드가 항상 실행돼야 한다. 이는 쿼럼 기반 클러스터 애플리케이션인 경우 특히 그렇다. 이런 이유로 쿠버네티스는 스케일 다운 드으이 작업을 수행할 경우에도 유지돼야 하는 최소 파드 개수를 지정하는 방법을 제공한다.		*특정 서비스에서는 최소 개수의 파드가 항상 실행돼야 한다. 이는 쿼럼 기반 클러스터 애플리케이션인 경우 특히 그렇다. 이런 이유로 쿠버네티스는 스케일 다운 드으이 작업을 수행할 경우에도 유지돼야 하는 최소 파드 개수를 지정하는 방법을 제공한다.
	== 고급 스케줄링 ==		== 고급 스케줄링 ==

			Extend Resource 이야기는 없네요.. 실무에서는 그게 유연하게 쓸수 있어서 많이쓰는데.. - [bluemir]
	=== 테인트와 톨러레이션을 사용해 특정 노드에서 파드 실행 제한 ===		=== 테인트와 톨러레이션을 사용해 특정 노드에서 파드 실행 제한 ===
	* p684		* p684

159.153.218.10 at 07:33, 16 November 2021

2021-11-16T07:33:09Z

@@ Line 1,912: / Line 1,912: @@
 ** 생성된 다섯 개의 파드 중 네 개는 node1에 배포됐으나 하나는 node2에 배포됐다. 왜 파드 중 하나가 node1 대신 node2에 배포돼쓸까? 그 이유는 스케줄러가 파드를 스케줄링 할 위치를 결정하는 데 노드의 어피니티 우선순위 지정 기능 외에도 다른 우선순위 지정기능을 사용하기 때문이다. 그중 하나다 Selector-spreadPriority 기능이다. 이 기능은 동일한 레플리카셋 또는 서비스에 속하는 파드를 여러 노드에 분산시켜 노드 장애로 인해 전체 서비스가 중단되지 않도록 한다. 이는 파드 중 하나가 node2에 스케줄링된 원인일 가능성이 높다.
 === 파드 어피니티와 안티-어피니티를 이용해 파드 함께 배치하기 ===
 == 애플리케이션 개발을 위한 모범 사례 ==
 == 쿠버네티스의 확장 ==

159.153.218.10 at 07:23, 16 November 2021

2021-11-16T07:23:04Z

@@ Line 1,851: / Line 1,851: @@
 ** 테인트는 키와 효과만 갖고 있고, 값을 꼭 필요로 하지 않는다. 톨러레이션은 Equal 연산자를 지정해 특정한 값을 허용하거나, Exists 연산자를 사용해 특정 테인트 키에 여러값을 허용할 수 있다.
 === 노드 어피니티를 사용해 파드를 특정 노드로 유인하기 ===
 === 파드 어피니티와 안티-어피니티를 이용해 파드 함께 배치하기 ===
 == 애플리케이션 개발을 위한 모범 사례 ==
 == 쿠버네티스의 확장 ==

159.153.218.10 at 07:05, 16 November 2021

2021-11-16T07:05:34Z

← Older revision		Revision as of 07:05, 16 November 2021
Line 1,840:		Line 1,840:
	** NoExecuete: 스케줄링에만 영향을 주는 NoSchedule이나 PreferNoSchedule과 달리, NoExecute는 노드에서 이미 실행 중인 파드에도 영향을 준다. NoExecute 테인트를 노드에 추가하면 해당 노드에서 이미 실행 중이지만 NoExecute 테인트를 허용하지 않는 파드는 노드에서 제거된다.		** NoExecuete: 스케줄링에만 영향을 주는 NoSchedule이나 PreferNoSchedule과 달리, NoExecute는 노드에서 이미 실행 중인 파드에도 영향을 준다. NoExecute 테인트를 노드에 추가하면 해당 노드에서 이미 실행 중이지만 NoExecute 테인트를 허용하지 않는 파드는 노드에서 제거된다.
	* 노드에 사용자 정의 테인트 추가하기		* 노드에 사용자 정의 테인트 추가하기
	$ kubectl taint node node1.k8s node-type=production:NoSchedule		$ kubectl taint node node1.k8s node-type=production:NoSchedule
			* 파드에 톨러레이션 추가
			spec:
			tolerations:
			- key: node-type
			Operator: Equal
			value: production
			effect: NoSchedule
			* p689
			** 테인트는 키와 효과만 갖고 있고, 값을 꼭 필요로 하지 않는다. 톨러레이션은 Equal 연산자를 지정해 특정한 값을 허용하거나, Exists 연산자를 사용해 특정 테인트 키에 여러값을 허용할 수 있다.
	=== 노드 어피니티를 사용해 파드를 특정 노드로 유인하기 ===		=== 노드 어피니티를 사용해 파드를 특정 노드로 유인하기 ===
	=== 파드 어피니티와 안티-어피니티를 이용해 파드 함께 배치하기 ===		=== 파드 어피니티와 안티-어피니티를 이용해 파드 함께 배치하기 ===

159.153.218.10 at 06:56, 16 November 2021

2021-11-16T06:56:05Z

@@ Line 1,824: / Line 1,824: @@
 == 고급 스케줄링 ==
 === 테인트와 톨러레이션을 사용해 특정 노드에서 파드 실행 제한 ===
 === 노드 어피니티를 사용해 파드를 특정 노드로 유인하기 ===
 === 파드 어피니티와 안티-어피니티를 이용해 파드 함께 배치하기 ===