Monday, February 12, 2018

Kubernetes




In Kubernetes, a volume can be thought of as a directory which is accessible to the containers in a pod. We have different types of volumes in Kubernetes and the type defines how the volume is created and its content.

  • emptyDir − It is a type of volume that is created when a Pod is first assigned to a Node. It remains active as long as the Pod is running on that node. The volume is initially empty and the containers in the pod can read and write the files in the emptyDir volume. Once the Pod is removed from the node, the data in the emptyDir is erased.


https://stackoverflow.com/questions/51718202/helm-how-to-define-release-name-value
It's the value of the helm install --name parameter, or absent this, a name Helm chooses itself. If you're checking what might be generated via helm template that also takes a --name parameter.

Troubleshooting

Init:ErrorAn Init Container has failed to execute.
Init:CrashLoopBackOffAn Init Container has failed repeatedly.
  -f, --values valueFiles        specify values in a YAML file (can specify multiple) (default [])
co


https://serverfault.com/questions/209461/lvm-performance-overhead
https://www.digitalocean.com/community/tutorials/an-introduction-to-helm-the-package-manager-for-kubernetes
Setting up a single application can involve creating multiple interdependent Kubernetes resources – such as pods, services, deployments, and replicasets – each requiring you to write a detailed YAML manifest file.
Helm is a package manager for Kubernetes that allows developers and operators to more easily package, configure, and deploy applications and services onto Kubernetes clusters.
Helm can:
  • Install software.
  • Automatically install software dependencies.
  • Upgrade software.
  • Configure software deployments.
  • Fetch software packages from repositories.
Helm provides this functionality through the following components:
  • A command line tool, helm, which provides the user interface to all Helm functionality.
  • A companion server component, tiller, that runs on your Kubernetes cluster, listens for commands from helm, and handles the configuration and deployment of software releases on the cluster.
  • The Helm packaging format, called charts.
  • An official curated charts repository with prepackaged charts for popular open-source software projects.
Helm packages are called charts, and they consist of a few YAML configuration files and some templates that are rendered into Kubernetes manifest files

package-name/
  charts/
  templates/
  Chart.yaml
  LICENSE
  README.md
  requirements.yaml
  values.yaml
These directories and files have the following functions:
  • charts/: Manually managed chart dependencies can be placed in this directory, though it is typically better to use requirements.yaml to dynamically link dependencies.
  • templates/: This directory contains template files that are combined with configuration values (from values.yaml and the command line) and rendered into Kubernetes manifests. The templates use the Go programming language's template format.
  • Chart.yaml: A YAML file with metadata about the chart, such as chart name and version, maintainer information, a relevant website, and search keywords.
  • LICENSE: A plaintext license for the chart.
  • README.md: A readme file with information for users of the chart.
  • requirements.yaml: A YAML file that lists the chart's dependencies.
  • values.yaml: A YAML file of default configuration values for the chart.
The helm command can install a chart from a local directory, or from a .tar.gz packaged version of this directory structure. These packaged charts can also be automatically downloaded and installed from chart repositories or repos.
https://medium.com/ingeniouslysimple/deploying-kubernetes-applications-with-helm-81c9c931f9d3
Helm is a tool for managing Kubernetes charts. Charts are packages of pre-configured Kubernetes resources.
A chart is organized as a collection of files inside of a directory.

$ helm repo update              # Make sure we get the latest list of charts
$ helm install stable/mysql

$ helm init --history-max 200

TIP: Setting --history-max on helm init is recommended as configmaps and other objects in helm history can grow large in number if not purged by max limit. Without a max history set the history is kept indefinitely, leaving a large number of records for helm and tiller to maintain.

This will install Tiller into the Kubernetes cluster you saw with kubectl config current-context.
TIP: Want to install into a different cluster? Use the --kube-context flag.
TIP: When you want to upgrade Tiller, just run helm init --upgrade.
helm init
kubectl -n kube-system get po


minikube addons enable registry-creds seemed to address the problem of "no credentials on this request".
https://blog.thecodeteam.com/2017/03/16/kubernetes-scaleio-support/
https://www.theregister.co.uk/2018/03/01/dell_stops_swonly_sales_of_scaleio_virtual_san/
http://www.cultofanarchy.org/dell-emc-scaleio-an-enterprise-grade-solution-with-awful-scalability/

All that has changed in recent days though. A change in strategy means that in future, ScaleIO will only be available inside Dell EMC VXRack FLEX hyper converged systems.

https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/
The dynamic provisioning feature eliminates the need for cluster administrators to pre-provision storage. Instead, it automatically provisions storage when it is requested by users


To enable dynamic provisioning, a cluster administrator needs to pre-create one or more StorageClass objects for users. StorageClass objects define which provisioner should be used and what parameters should be passed to that provisioner when dynamic provisioning is invoked. The following manifest creates a storage class “slow” which provisions standard disk-like persistent disks.

https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0

A ClusterIP service is the default Kubernetes service. It gives you a service inside your cluster that other apps inside your cluster can access. There is no external access.
Turns out you can access it using the Kubernetes proxy!

Start the Kubernetes Proxy:

kubectl proxy --port=8080
Now, you can navigate through the Kubernetes API to access this service using this scheme:

http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/
http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/












A NodePort service is the most primitive way to get external traffic directly to your service. NodePort, as the name implies, opens a specific port on all the Nodes (the VMs), and any traffic that is sent to this port is forwarded to the service.
There is also an additional port called the nodePort that specifies which port to open on the nodes. If you don’t specify this port, it will pick a random port. Most of the time you should let Kubernetes choose the port; as thockin says, there are many caveats to what ports are available for you to use.
There are many downsides to this method:
  1. You can only have once service per port
  2. You can only use ports 30000–32767
  3. If your Node/VM IP address change, you need to deal with that
https://stackoverflow.com/questions/40767164/expose-port-in-minikube
$ kubectl run hello-minikube --image=gcr.io/google_containers/echoserver:1.4 --port=8080
deployment "hello-minikube" created
$ kubectl expose deployment hello-minikube --type=NodePort
service "hello-minikube" exposed
$ kubectl get svc
NAME             CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
hello-minikube   10.0.0.102   <nodes>       8080/TCP   7s
kubernetes       10.0.0.1     <none>        443/TCP    13m

$ minikube service hello-minikube
Opening kubernetes service default/hello-minikube in default browser...
This command will open the specified service in your default browser. Here is the minikube service documentation: https://github.com/kubernetes/minikube/blob/master/docs/minikube_service.md
There is also a --url option for printing the url of the service which is what gets opened in the browser:
$ minikube service hello-minikube --url
http://192.168.99.100:31167
minikube ip


https://github.com/jordanwilson230/kubectl-plugins
  • Like kubectl exec, but offers a --user flag to exec as root (or any other user)
  • 'ssh' is a misnomer (it works by mounting a docker socket as a volume), but it's easier to work with as a command.
  • Kudos to mikelorant for thinking of the docker socket! :)
https://kubernetes.io/docs/tasks/debug-application-cluster/get-shell-running-container/
Get a shell to the running Container:
kubectl exec -it shell-demo -- /bin/bash
https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
To temporarily set the namespace for a request, use the --namespace flag.
For example:
$ kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
$ kubectl --namespace=<insert-namespace-name-here> get pods

$ kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>
# Validate it
$ kubectl config view | grep namespace
https://medium.com/devopslinks/deploying-multi-node-kubernetes-environment-in-your-local-machine-a66a1eb82e36
This uses DIND (docker in docker) and kubeadm to provision kubernetes, this would not be a good option if your filesystem is ‘btrfs’.
http://callistaenterprise.se/blogg/teknik/2017/12/20/kubernetes-on-docker-in-docker/
git clone https://github.com/Mirantis/kubeadm-dind-cluster.git
cd kubeadm-dind-cluster/fixed

NUM_NODES=3 ./dind-cluster-v1.11.sh up
brew install md5sha1sum
First, switch to the default namespace:
kubectl config set-context $(kubectl config current-context) --namespace=default
The default namespace should only contain one pre-created object, run the command:
kubectl get all

./dind-cluster-v1.W.sh down

./dind-cluster-v1.11.sh clean

First, switch to the default namespace:
kubectl config set-context $(kubectl config current-context) --namespace=default

https://stackoverflow.com/questions/51687893/how-do-i-get-the-minikube-nodes-in-a-local-cluster/51706547#51706547

https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/
A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rkt. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

Masters manage the cluster and the nodes are used to host the running applications.

When you deploy applications on Kubernetes, you tell the master to start the application containers. The master schedules the containers to run on the cluster's nodes. The nodes communicate with the master using the Kubernetes API, which the master exposes. End users can also use the Kubernetes API directly to interact with the cluster.


https://github.com/IBM/Scalable-Cassandra-deployment-on-Kubernetes
kubectl scale --replicas=3 statefulset/cassandra

https://github.com/freedev/solrcloud-zookeeper-kubernetes

minikube service list


https://kubernetes.io/docs/tutorials/stateful-application/cassandra/
minikube start --memory 5120 --cpus=4
kubectl create -f https://k8s.io/examples/application/cassandra/cassandra-service.yaml
kubectl get svc cassandra

kubectl create -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml
kubectl get statefulset cassandra
kubectl get pods -l="app=cassandra"
kubectl exec -it cassandra-0 -- nodetool status
kubectl edit statefulset cassandra
  1. grace=$(kubectl get po cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \
      && kubectl delete statefulset -l app=cassandra \
      && echo "Sleeping $grace" \
      && sleep $grace \
      && kubectl delete pvc -l app=cassandra
  2. Run the following command to delete the Cassandra Service.
    kubectl delete service -l app=cassandra
Local Persistent Volumes for Kubernetes Goes Beta
https://kubernetes.io/blog/2018/04/13/local-persistent-volumes-beta/
  • Caching of datasets that can leverage data gravity for fast processing
  • Distributed storage systems that shard or replicate data across multiple nodes. Examples include distributed datastores like Cassandra, or distributed file systems like Gluster or Ceph.
https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature
https://matthewpalmer.net/kubernetes-app-developer/articles/multi-container-pod-design-patterns.html
The Multi-Pod Lifestyle


emptyDir—A simple empty directory used for storing transient data.
hostPath—Used for mounting directories from the worker node’s filesystem into the pod.
gitRepo—A volume initialized by checking out the contents of a Git repository.
nfs—An NFS share mounted into the pod.
gcePersistentDisk (Google Compute Engine Persistent Disk), awsElasticBlockStore (Amazon Web Services Elastic Block Store Volume), azureDisk (Microsoft Azure Disk Volume)—Used for mounting cloud provider-specific storage.
cinder, cephfs, iscsi, flocker, glusterfs, quobyte, rbd, flexVolume, vsphere-Volume, photonPersistentDisk, scaleIO—Used for mounting other types of network storage.
configMap, secret, downwardAPI—Special types of volumes used to expose certain Kubernetes resources and cluster information to the pod.
persistentVolumeClaim—A way to use a pre- or dynamically provisioned persistent storage.

a tmpfs filesystem (in memory instead of on disk)
volumes:
- name: html
  emptyDir:
    medium: Memory              
A sidecar container is a container that augments the operation of the main container of the pod
https://kubernetes.io/docs/getting-started-guides/minikube/
https://kubernetes.io/docs/tasks/tools/install-minikube/

https://kubernetes.io/docs/tasks/tools/install-kubectl/
brew install kubectl
kubectl version
https://github.com/kubernetes/minikube/releases

curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.25.0/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/


minikube start
~/.kube/config

kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.4 --port=8080
deployment "hello-minikube" created
kubectl expose deployment hello-minikube --type=NodePort
service "hello-minikube" exposed

kubectl get pod

# We can see that the pod is now Running and we will now be able to curl it:
curl $(minikube service hello-minikube --url)


kubectl delete deployment hello-minikube
minikube stop

To be able to work with the docker daemon on your mac/linux host use the docker-env command in your shell:
eval $(minikube docker-env)
You should now be able to use docker on the command line on your host mac/linux machine talking to the docker daemon inside the minikube VM:
docker ps

一篇带你走近Kubernetes概貌与原理
一句话概括的话Kubernetes是一个庞大的工具体系,在这个工具体系下,你将会拥有众多平时你需要花费不少精力来实现的诸如一些运维保障的功能以及弹性调度,故障自愈等等功能。。
在这个 壳(POD)里, 享有一些特性: 共用网络空间,hostname, 存储等
一个pod里运行的容器一定是在同一个地方,不会被拆散,因为它们是一个整体。
POD是kubernetes组件调度的最小单元
POD中的容器也分为几种类型: 服务类, Web类, 有状态存储类,短时任务类, 定时任务类等等
其次, POD不可能由我们人工去创建,加之有上述的这些类型, 如果都是人工去做还要毛线K8S, 还要毛子POD这一层概念。。。
所以: 各种控制器出现了, 如Deployment,它一般去负责运行服务类的Web类的POD, 并且为pod状态做一些保障性工作等等, Statefulset与deployment类似,他是专门为有状态服务而设计的,Job Cronjob控制器更不用多说
所以总结一句,POD需要东西来创建,来运行,来调度,来保障运行状态, 谁来保障?各种类型的控制器是也
kubernetes的调度策略十分庞大,最常见的 如 NodeSelector(你可以把一个POD指定调度到带有特定标签的计算节点去),调度策略统一

首先说明K8s中有一个叫副本控制器的东西,它可能是K8S里其他比如deployment控制器都会用到的一个控制器,它负责可以对一个POD进行复制的效果,一个POD,可以复制多份,形成副本集。
其次需要说明任何一个控制器都有自己的使命,比如deployment控制器它需要保证它运行的POD一直处于设置的实例数。如果用户的POD被检测到挂了(如何检测见下文),deployment会根据设定无条件重新创建该POD,并终止清除已有的挂掉的POD实例
https://blog.deimos.fr/2018/06/24/running-cassandra-on-kubernetes/
To reduce performance issues as well and reduce cluster failure in case of an issue, I should avoid getting multiple instances on the same physocal host



https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
Run kubectl get nodes to get the names of your cluster’s nodes. Pick out the one that you want to add a label to, and then run kubectl label nodes <node-name> <label-key>=<label-value> to add a label to the node you’ve chosen.

  1. you can constrain against labels on other pods running on the node (or other topological domain), rather than against labels on the node itself, which allows rules about which pods can and cannot be co-located
https://medium.com/kokster/scheduling-in-kubernetes-part-2-pod-affinity-c2b217312ae1

https://kubernetes.io/docs/concepts/architecture/nodes/
A node is a worker machine in Kubernetes, previously known as a minion. A node may be a VM or physical machine, depending on the cluster. Each node contains the services necessary to run pods and is managed by the master components. The services on a node include the container runtime, kubelet and kube-proxy.


https://hackernoon.com/what-is-helm-and-why-you-should-love-it-74bf3d0aafc
Helm is the first application package manager running atop Kubernetes. It allows describing the application structure through convenient helm-charts and managing it with simple commands.

The main benefit of this approach is the ability to consider scalability from the start. The charts of all the images used by Helm are stored in a registry called Helm Workspace, so the DevOps teams can search them and add to their projects with ease.


https://docs.helm.sh/using_helm/
brew install kubernetes-helm
helm init
helm search
helm install stable/jenkins
minikube service original-llama-jenkins

$ helm repo update              # Make sure we get the latest list of charts
$ helm install stable/mysql
helm ls
helm repo update
We’re able to deploy our entire application by pointing helm at a directory containing all of our Kubernetes resources, using one command line call.

Helm keeps track of how many times an application has been deployed on a cluster. You can inspect what revision number you’re currently at, and you can even rollback to previous revisions if necessary. Doing this with kubectl is possible, but it's much more difficult than just running helm rollback <APPLICATION> <REVISION_NUMBER>.
With Helm, you define configuration values in a separate values.yaml file and reference those in other resource files. Helm injects the values at deployment time.
This has the huge benefit of centralising your configuration values. If you update a value, then all resources depending on it get that updated value. No more forgetting to update one resource!
helm package helloworld-chart --debug
## helloworld-chart-0.1.0.tgz file was created
helm install helloworld-chart-0.1.0.tgz --name helloworld
kubectl get svc --watch # wait for a IP
docker build -t hello-world .
docker run -p 80:8005 hello-world
docker tag hello-world {your_dockerhub_user}/hello-world:2.0
docker push {your_dockerhub_user}/hello-world:2.0
helm upgrade helloworld helloworld-chart-2.0.0.tgz
helm rollback helloworld 1

  • Chart.yaml describes the chart, as in it’s name, description and version.
  • values.yaml is stores variables for the template files templates directory. If you have more complex deployment needs, that falls outside the default templates capability, edit the files in this directory. They are normal Go templates, Hugo (https://gohugo.io) which btw powers this blog, have a nice Go template primer (https://gohugo.io/templates/go-templates/), if you need more information on how to work with Go templates.
  • NOTES.txt is used to give information after deployment to the user that deployed the chart. For example it might explain how to use the chart, or list default settings, etc. For this post I will keep the default message in it.
 helm lint



Labels

Review (572) System Design (334) System Design - Review (198) Java (189) Coding (75) Interview-System Design (65) Interview (63) Book Notes (59) Coding - Review (59) to-do (45) Linux (43) Knowledge (39) Interview-Java (35) Knowledge - Review (32) Database (31) Design Patterns (31) Big Data (29) Product Architecture (28) MultiThread (27) Soft Skills (27) Concurrency (26) Cracking Code Interview (26) Miscs (25) Distributed (24) OOD Design (24) Google (23) Career (22) Interview - Review (21) Java - Code (21) Operating System (21) Interview Q&A (20) System Design - Practice (20) Tips (19) Algorithm (17) Company - Facebook (17) Security (17) How to Ace Interview (16) Brain Teaser (14) Linux - Shell (14) Redis (14) Testing (14) Tools (14) Code Quality (13) Search (13) Spark (13) Spring (13) Company - LinkedIn (12) How to (12) Interview-Database (12) Interview-Operating System (12) Solr (12) Architecture Principles (11) Resource (10) Amazon (9) Cache (9) Git (9) Interview - MultiThread (9) Scalability (9) Trouble Shooting (9) Web Dev (9) Architecture Model (8) Better Programmer (8) Cassandra (8) Company - Uber (8) Java67 (8) Math (8) OO Design principles (8) SOLID (8) Design (7) Interview Corner (7) JVM (7) Java Basics (7) Kafka (7) Mac (7) Machine Learning (7) NoSQL (7) C++ (6) Chrome (6) File System (6) Highscalability (6) How to Better (6) Network (6) Restful (6) CareerCup (5) Code Review (5) Hash (5) How to Interview (5) JDK Source Code (5) JavaScript (5) Leetcode (5) Must Known (5) Python (5)

Popular Posts