New Course Update: Kuberentes Multi Container Pods Course

content/learning-paths/11111111-1111-1111-1111-111111111111/mastering-kubernetes-for-engineers/kubernetes-multi-container-pods/_index.md

@@ -0,0 +1,13 @@
+---
+type: "course"
+title: "Kubernetes Multi-Container Pods"
+description: "Learn how to design and deploy multi-container Pods in Kubernetes using patterns like sidecars, ambassadors, and adapters to extend application functionality and share resources effectively."
+weight: 5
+banner: "images/kubernetes-icon.svg"
+tags: [kubernetes, containers]
+categories: "kubernetes"
+level: "beginner"
+---
+
+A course to help you design and deploy multi-container Pods in Kubernetes using sidecar, ambassador, and adapter patterns for shared resources and extended functionality.
+

content/learning-paths/11111111-1111-1111-1111-111111111111/mastering-kubernetes-for-engineers/kubernetes-multi-container-pods/conclusion/_index.md

@@ -0,0 +1,11 @@
+---
+type: "module"
+id: "conclusion"
+description: ""
+title: "Conlusion"
+weight: 6
+---
+
+# Conclusion
+
+While sidecar patterns offer great flexibility, they're not a silver bullet. Each added sidecar introduces complexity, consumes resources, and potentially increases operational overhead. Always evaluate simpler alternatives first. The key is strategic implementation: use sidecars as precision tools to solve specific architectural challenges, not as a default approach. When used correctly, they can improve security, networking, and configuration management in containerized environments. Choose wisely, implement carefully, and let your sidecars elevate your container ecosystem.

content/learning-paths/11111111-1111-1111-1111-111111111111/mastering-kubernetes-for-engineers/kubernetes-multi-container-pods/essential-multi-container-patterns/_index.md

@@ -0,0 +1,49 @@
+---
+type: "module"
+id: "essential-multi-container-patterns"
+description: ""
+title: "Essential Multi-Container Patterns"
+weight: 5
+---
+
+# Essential Multi-Container Patterns
+
+Directions: To expand a category and view its details, select the plus (+) icon next to the category name.
+
+### Init container pattern
+
+The Init container pattern is used to execute (often critical) setup tasks before the main application container starts. Unlike regular containers, init containers run to completion and then terminate, ensuring that preconditions for the main application are met. It is ideal for:
+
+- Preparing configurations
+- Loading secrets
+- Verifying dependency availability
+- Running database migrations
+
+The init container ensures your application starts in a predictable, controlled environment without code modifications
+
+### Ambassador pattern
+
+An ambassador container provides Pod-local helper services that expose a simple way to access a network service. Typically, ambassador containers send network requests on behalf of an application container and handle challenges such as service discovery, peer identity verification, or encryption in transit. It is ideal when you need to:
+
+- Offload client connectivity concerns
+- Implement language-agnostic networking features
+- Add security layers like TLS
+- Create robust circuit breakers and retry mechanisms
+
+### Configuration helper
+
+A configuration helper sidecar dynamically provides configuration updates to an application, ensuring it always has access to the latest settings without disrupting the service. Often, the helper needs to provide an initial configuration before the application can start successfully. Use cases:
+
+1. Fetching environment variables and secrets
+2. Polling configuration changes
+3. Decoupling configuration management from application logic
+
+### Adapter pattern
+
+An adapter (or sometimes façade) container enables interoperability between the main application container and external services. It does this by translating data formats, protocols, or APIs. It is ideal for:
+
+1. Transforming legacy data formats
+2. Bridging communication protocols
+3. Facilitating integration between mismatched services
+
+

content/learning-paths/11111111-1111-1111-1111-111111111111/mastering-kubernetes-for-engineers/kubernetes-multi-container-pods/kubernetes-implementation/_index.md

@@ -0,0 +1,24 @@
+---
+type: "module"
+id: "ubernetes-implementation"
+description: ""
+title: "Kubernetes Implementation"
+weight: 3
+---
+
+In Kubernetes, [sidecar containers](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/) operate within the same Pod as the main application, enabling communication and resource sharing. Does this sound just like defining multiple containers along each other inside the Pod? It does, and this is how sidecar containers had to be implemented before Kubernetes v1.29.0, which introduced native support for sidecars. Sidecar containers can now be defined within a Pod manifest using the spec.initContainers field. What makes it a sidecar container is that you specify it with restartPolicy: Always.
+
+You can see an example of this below, which is a partial snippet of the full Kubernetes manifest:
+
+```yaml
+initContainers:
+  - name: logshipper
+    image: alpine:latest
+    restartPolicy: Always
+  command: ['sh', '-c', 'tail -F /opt/logs.txt']
+    volumeMounts:
+    - name: data
+        mountPath: /opt
+```
+
+That field name, spec.initContainers may sound confusing. Why is it necessary to include an entry in the spec.initContainers array when defining a sidecar container? spec.initContainers are run to completion just before the main application starts, so they’re one-off. In contrast, sidecars often run in parallel to the main app container. It’s the spec.initContainers with restartPolicy:Always which differentiates classic [init containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) from Kubernetes-native sidecar containers and ensures they are always up.

content/learning-paths/11111111-1111-1111-1111-111111111111/mastering-kubernetes-for-engineers/kubernetes-multi-container-pods/overview/_index.md

@@ -0,0 +1,13 @@
+---
+type: "module"
+id: "overview"
+description: ""
+title: "Overview"
+weight: 1
+---
+
+
+As cloud native architectures continue to evolve, Kubernetes has become the go-to platform for deploying complex, distributed systems. One of the most powerful yet nuanced design patterns in this ecosystem is the sidecar pattern. This technique enables developers to extend application functionality without requiring in-depth knowledge of the source code.
+
+
+The microcourse provides an overview of multi-container Pods in Kubernetes, explaining how they enable closely coupled containers to share resources, such as storage and networking, within a single deployment unit. It highlights common patterns—such as sidecars, ambassadors, and adapters—and offers guidance on when and how to use multi-container Pods effectively in real-world applications.

content/learning-paths/11111111-1111-1111-1111-111111111111/mastering-kubernetes-for-engineers/kubernetes-multi-container-pods/test.md

@@ -0,0 +1,52 @@
+---
+title: "Test"
+passing_percentage: 70
+questions:
+    - id: "q1"
+      text: "What is one key benefit of using multi-container Pods in Kubernetes?"
+      type: "single-answer"
+      marks: 2
+      options:
+        - id: "a"
+          text: "Improved logging for cluster nodes"
+        - id: "b"
+          text: "Shared storage and networking between containers"
+          is_correct: true
+        - id: "c"
+          text: "Increased number of Pods per node"
+        - id: "d"
+          text: "Guaranteed low CPU usage"
+
+    - id: "q2"
+      text: "What is a sidecar container commonly used for"
+      type: "single-answer"
+      marks: 2
+      options:
+        - id: "a"
+          text: "Monitoring and logging support for the main container"
+          is_correct: true
+        - id: "b"
+          text: "Managing RBAC roles"
+        - id: "c"
+          text: "Scheduling other Pods"
+        - id: "d"
+          text: "Limiting memory acccess"
+
+
+    - id: "q3"
+      text: "Why should multi-container Pods be used cautiously?"
+      type: "single-answer"
+      marks: 2
+      options:
+        - id: "a"
+          text: "Because, multi-container Pods always require manual scaling."
+        - id: "b"
+          text: "Because, multi-container Pods are not supported on managed Kubernetes services."
+        - id: "c"
+          text: "Because, multi-container Pods can introduce complexity, latency, and tight coupling."
+          is_correct: true
+        - id: "d"
+          text: "Because, multi-container Pods use different network policies than single-container Pods."
+
+type: "test"
+---

content/learning-paths/11111111-1111-1111-1111-111111111111/mastering-kubernetes-for-engineers/kubernetes-multi-container-pods/the-origins-of-the-sidecar-pattern/_index.md

@@ -0,0 +1,14 @@
+---
+type: "module"
+id: "the-origins-of-the-sidecar-pattern"
+description: ""
+title: "The Origins of the Sidecar Pattern"
+weight: 2
+---
+
+Think of a sidecar like a trusty companion motorcycle attachment. Historically, IT infrastructures have always used auxiliary services to handle critical tasks.
+
+Before containers, we relied on background processes and helper daemons to manage logging, monitoring, and networking. The microservices revolution transformed this approach, making sidecars a structured and intentional architectural choice. With the rise of microservices, the sidecar pattern became more clearly defined, allowing developers to offload specific responsibilities from the main service without altering its code.
+Service meshes, such as Istio and Linkerd, have popularized sidecar proxies, demonstrating how these companion containers can elegantly handle observability, security, and traffic management in distributed systems.
+
+![Side Car](stock-image.jpg)

content/learning-paths/11111111-1111-1111-1111-111111111111/mastering-kubernetes-for-engineers/kubernetes-multi-container-pods/when-to-embrace-or-avoid-sidecars/_index.md

@@ -0,0 +1,29 @@
+---
+type: "module"
+id: "when-to-embrace-or-avoid-sidecars"
+description: ""
+title: "When To Embrace (or Avoid) Sidecars"
+weight: 4
+---
+
+While the sidecar pattern can be helpful in many cases, it is generally not the preferred approach unless the use case justifies it. Adding a sidecar increases complexity, resource consumption, and potential network latency. Instead, simpler alternatives such as built-in libraries or shared infrastructure should be considered first.
+
+**Directions**: Select each tab below to learn more about when you should use or avoid sidecars.
+
+### Deploy A Sidecar When
+
+1. You need to extend application functionality without touching the original code
+2. Implementing cross-cutting concerns like logging, monitoring, or security
+3. Working with legacy applications requiring modern networking capabilities
+4. Designing microservices that demand independent scaling and updates8
+
+![ok](ok.png)
+
+### Proceed with Caution If
+
+1. Resource efficiency is your primary concern
+2. Minimal network latency is critical
+3. Simpler alternatives exist
+4. You want to minimize troubleshooting complexity
+
+![Caution](Caution.png)