kube

02-setup-kubernetes-cluster/README.md

@@ -0,0 +1,29 @@
+## Kubernetes? 
+
+> **Kubernetes (K8s in short) is an `open-source container orchestration platform` introduced by Google in 2014. It is a successor of Borg, Google’s in-house orchestration system that accumulated over a decade of the tech giant’s experience of running large enterprise workloads in production.**
+
+> **In 2014, Google decided to further container ecosystem by sharing Kubernetes with the cloud native community. Kubernetes became the first graduated project of the newly created `Cloud Native Community Foundation (CNCF)`, an organization conceived by Google and the Linux Foundation as the main driver of the emerging cloud native movement.**
+
+> **The platform’s main purpose is to automate deployment and management `(e.g., update, scaling, security, networking) of containerized application in large distributed computer clusters.` To this end, the platform offers a number of API primitives, deployment options, networking, container and storage interfaces, built-in security, and other useful features.**
+
+## Here’s what a basic process of running applications in Kubernetes looks like.
+
+> **First, you package your application with all its dependencies into a Linux container (for example, with Docker).**
+
+> **Then, you create an API resource in Kubernetes where you specify the container image to use, the number of replicas to run, ports, volumes, update policy, configuration, and other parameters.**
+
+> **Third, you register the API object with the Kubernetes API server.**
+
+> **Thereafter, Kubernetes works to maintain the desired state of the API resource you declared. `For example,`**
+
+   * ***it tries to run the number of replicas you specified,***
+   * ***re-schedule the app onto another node if the one hosting it failed,*** 
+   * ***perform liveness and readiness probes, etc.***
+
+> **In sum, Kubernetes provides a way to maintain the desired state of your application. With this platform, you declare how you want your app to be run and Kubernetes takes care of it. Kubernetes also allows administrators to efficiently manage cluster resources both on-premises and in the cloud.**
+
+
+
+## Setup Kubernetes Cluster 
+
+>>> ### [follow-cluster-setup-docs-here](https://github.com/lerndevops/kubernetes/blob/master/1-intall/README.md)

03-install-helm/README.md

@@ -0,0 +1,62 @@
+## Helm3 Architecture 
+
+### Client Only Architecture
+
+> Helm 3 has a client-only architecture with the client still called helm. As seen in the following diagram, it operates similar to the Helm 2 client, but the client interacts directly with the Kubernetes API server.
+
+> Helm 3 is a single-service architecture. One executable is responsible for implementing Helm. There is no client/server split, nor is the core processing logic distributed among components.
+
+> Implementation of Helm 3 is a single command-line client with no in-cluster server or controller. This tool exposes command-line operations, and unilaterally handles the package management process.
+
+### ***The implementation has two distinct parts:***
+
+1.    The command line façade, which translates commands, subcommands, flags, and arguments into a Helm operation
+2.    The Helm library, which provides the logic for executing all Helm operations.
+
+### **By design, the Helm library must be usable as a standalone library.**
+
+![helm-test](../img/helm3-architecture.PNG)
+
+### Install Helm version3
+
+```
+curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
+chmod 700 get_helm.sh
+./get_helm.sh
+```
+
+```
+root@kube-master:~# helm version --short
+v3.0.2+g19e47ee
+```
+
+### [Follow the Documentation for More](https://helm.sh/docs/intro/install/)
+
+## Helm2 Architecture --- ***Not Used Anymore***
+
+> **Helm2 has two major components:**
+
+>> ***The `Helm Client` is a command-line client for end users. The client is responsible for the following domains:***
+
+* Local chart development
+* Managing repositories
+* Interacting with the Tiller server
+* Sending charts to be installed
+* Asking for information about releases
+* Requesting upgrading or uninstalling of existing releases
+
+
+>> ***The `Tiller Server` is an in-cluster server that interacts with the Helm client, and interfaces with the Kubernetes API server. The server is responsible for the following:***
+
+* Listening for incoming requests from the Helm client
+* Combining a chart and configuration to build a release
+* Installing charts into Kubernetes, and then tracking the subsequent release
+* Upgrading and uninstalling charts by interacting with Kubernetes
+
+![helm2-architecture](../img/helm2-architecture.PNG)
+
+### In a nutshell, the client is responsible for managing charts, and the server is responsible for managing releases.
+
+### Install Helm version2  
+
+### [Follow the Documentation to Install](https://v2.helm.sh/docs/using_helm/#installing-helm)