Kubernetes/Deployment, ReplicaSet and Pod - Revision history

Pio2pio: /* Statefulset */

2020-06-18T15:09:19Z

Statefulset

← Older revision		Revision as of 17:09, 18 June 2020
Line 381:		Line 381:
	<source lang=bash>		<source lang=bash>
	# Exec to any of pods		# Exec to any of pods
	_<sts>_-#._svc_.__ns___.svc.cluster.local		# _<sts>_-#._svc_.__ns___.svc.cluster.local
	watch dig +short kubeweb-0.nginx.default.svc.cluster.local kubeweb-0.nginx.default.svc.cluster.local		watch dig +short kubeweb-0.nginx.default.svc.cluster.local kubeweb-0.nginx.default.svc.cluster.local
	10.35.66.166		10.35.66.166

2020-06-18T15:08:47Z

Statefulset

@@ Line 358: / Line 358: @@
          image: nginx:1.16.0</source>
 |}
 = References =

2020-06-18T15:03:09Z

Statefulset

← Older revision		Revision as of 17:03, 18 June 2020
Line 307:		Line 307:
	name: kubeweb		name: kubeweb
	spec:		spec:
	serviceName: "nginx"		# headless svc, creates ordinarIndex names (stable networkID)
			# in form: <sts>-<$index>.<svc>.<ns>.svc.cluster.local
			serviceName: "nginx" # <- headless service
	replicas: 2		replicas: 2
	selector:		selector:
Line 356:		Line 358:
	image: nginx:1.16.0</source>		image: nginx:1.16.0</source>
	\|}		\|}

	= References =		= References =
	*[https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ Deployments]		*[https://kubernetes.io/docs/concepts/workloads/controllers/deployment/ Deployments]

2020-01-28T12:13:12Z

Deployment

@@ Line 8: / Line 8: @@
 * Ambassador pattern
 == Deployment ==
 ''Deployment'' kind provides all required application life-cycle for your applications. This is achieved by managing objects like ReplicaSet and Pod.

2019-10-19T23:34:13Z

Deployment

← Older revision		Revision as of 01:34, 20 October 2019
Line 1:		Line 1:
			= [https://matthewpalmer.net/kubernetes-app-developer/articles/multi-container-pod-design-patterns.html Multi-Container Pod Design Patterns in Kubernetes] =
			There are three common design patterns and use-cases for combining multiple containers into a single pod. We’ll walk through the sidecar pattern, the adapter pattern, and the ambassador pattern. Look to the end of the post for example YAML files for each of these.
			:[[File:ClipCapIt-191020-003257.PNG]]


			* Sidecar pattern - common sidecar containers are logging utilities, sync services, watchers, and monitoring agents
			* Adapter pattern
			* Ambassador pattern

	== Deployment ==		== Deployment ==
	''Deployment'' kind provides all required application life-cycle for your applications. This is achieved by managing objects like ReplicaSet and Pod.		''Deployment'' kind provides all required application life-cycle for your applications. This is achieved by managing objects like ReplicaSet and Pod.

2019-10-17T20:30:00Z

Deployment

← Older revision		Revision as of 22:30, 17 October 2019
Line 73:		Line 73:
	\|}		\|}

	;Note		;[https://stackoverflow.com/questions/57197095/why-do-we-need-a-port-containerport-in-a-kuberntes-deployment-container-definiti Note]
	<code>containerPort</code> the purpose of defining is purely for [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#container-v1-core documentation]. It is only used by other developers to understand the port that the container listens to. Kubernetes borrows this idea from docker which does the same with [https://docs.docker.com/engine/reference/builder/#expose <code>EXPOSE</code> command].		<code>containerPort</code> the purpose of defining is purely for [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#container-v1-core documentation]. It is only used by other developers to understand the port that the container listens to. Kubernetes borrows this idea from docker which does the same with [https://docs.docker.com/engine/reference/builder/#expose <code>EXPOSE</code> command].

2019-10-17T20:29:02Z

Deployment

← Older revision		Revision as of 22:29, 17 October 2019
Line 73:		Line 73:
	\|}		\|}

			;Note
			<code>containerPort</code> the purpose of defining is purely for [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#container-v1-core documentation]. It is only used by other developers to understand the port that the container listens to. Kubernetes borrows this idea from docker which does the same with [https://docs.docker.com/engine/reference/builder/#expose <code>EXPOSE</code> command].

	<code>~~containerPort~~</code> ~~is important to enable other services or pods to connect to~~ the ~~pod~~. ~~By default <tt>nginx</tt>~~ container ~~listens on port 80, but if we will not specify in the pod spec, no other pods or services will be able to connect to it~~.
			From Docker documentation: The <code>EXPOSE</code> instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container...

	== Create Deployment ==		== Create Deployment ==

2019-10-17T08:49:57Z

Deployment

← Older revision		Revision as of 10:49, 17 October 2019
Line 72:		Line 72:
	</source>		</source>
	\|}		\|}


			<code>containerPort</code> is important to enable other services or pods to connect to the pod. By default <tt>nginx</tt> container listens on port 80, but if we will not specify in the pod spec, no other pods or services will be able to connect to it.

	== Create Deployment ==		== Create Deployment ==

2019-10-17T07:14:40Z

Deployment

2019-10-17T06:58:06Z

Deployment

← Older revision		Revision as of 08:58, 17 October 2019
Line 54:		Line 54:
	spec:		spec:
	containers:		containers:
	- ~~name: main~~		- image: nginx:1.16.0</source>
	image: nginx:1.16.0</source>		name: main
	\| <source lang=yaml> apiVersion: v1		\| <source lang=yaml> apiVersion: v1
	kind: Pod		kind: Pod
Line 61:		Line 61:
	name: kuebapp-pod1		name: kuebapp-pod1
	labels:		labels:
			app: kubeapp
	tier: frontend		tier: frontend

	spec:		spec:
	containers:		containers:
	- ~~name: main~~		- image: nginx:1.16.0
	image: nginx:1.16.0</source>		name: main
			</source>
	\|}		\|}