k8s使用

一、start:
master启动：
kubeadm init

使用kubectl命令：
export KUBECONFIG=/etc/kubernetes/admin.conf

Weave net:
cat /proc/sys/net/bridge/bridge-nf-call-iptables
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

获取token:
kubeadm token list
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

worker node join:
kubeadm join --token 8vo675.yk0xi88xctth3xv2 192.168.216.91:6443 --discovery-token-ca-cert-hash sha256:53772ef117b5378aac39927ea2a7e422c2f3f0d6eab981eb0dd3fd74bfcd57fe

二、kubectl:
kubectl get nodes
kubectl get pods --all-namespaces
kubectl delete pod/memory-limit-deployment-797669bbc8-w2b64 --force --grace-period=0

三、tear down:
Talking to the master with the appropriate credentials, run:
kubectl drain <node name> --delete-local-data --force --ignore-daemonsets //将该node上的容器进行驱逐
kubectl delete node <node name>    //删除该node
Then, on the node being removed, reset all kubeadm installed state:
kubeadm reset

四、log：
查看cni的日志: sudo journalctl -xe | grep cni
系统日志：cat /var/log/messages

kubectl describe pod kubernetes-dashboard-849cd79b75-s2snt --namespace kube-system

kubectl logs -f pods/monitoring-influxdb-fc8f8d5cd-dbs7d -n kube-system

kubectl logs --tail 200 -f kube-apiserver -n kube-system |more

kubectl logs --tail 200 -f podname -n jenkins

journalctl -u kube-scheduler

journalctl -xefu kubelet

journalctl -u kube-apiserver

journalctl -u kubelet |tail

journalctl -xe

docker logs c36c56e4cfa3

五、Node的隔离与恢复
kubectl cordon k8s-node1    #将k8s-node1节点设置为不可调度模式（之前调度到此node上的pod可以正常运行，新的pod不会调度到此node上）
kubectl drain k8s-node1     #将k8s-node1设置为不可调度模式；并将当前运行在k8s-node1节点上的pod驱离，如果为默认调度器的话（replica controller会维护pod的副本数不变，也就是在schedulingAble node上增加相应的pod）

kubectl uncordon k8s-node1  #将节点重新设为调度模式（pod可以正常被调度到该node）

六、access Kubernetes API
curl http://localhost:8080/api/

七、words from kubernetes.io:
Node Spec:
Spec defines the behavior of a node
Node Status:
Most recently observed status of the node
Node Capacity: 
Capacity represents the total resources of a node
Describes the resources available on the node: CPU, memory and the maximum number of pods that can be scheduled onto the node
Node Allocatable:
Allocatable represents the resources of a node that are available for scheduling. Defaults to Capacity.

Requests and limits: 
If a Container exceeds its memory limit, it might be terminated. If it is restartable, the kubelet will restart it, as with any other type of runtime failure.
If a Container exceeds its memory request, it is likely that its Pod will be evicted whenever the node runs out of memory.
A Container might or might not be allowed to exceed its CPU limit for extended periods of time. However, it will not be killed for excessive CPU usage.
Although requests and limits can only be specified on individual Containers, it is convenient to talk about Pod resource requests and limits. A Pod resource request/limit for a particular resource type is the sum of the resource requests/limits of that type for each Container in the Pod

Scheduler:
The Kubernetes scheduler ensures that there are enough resources for all the pods on a node. It checks that the sum of the requests of containers on the node is no greater than the node capacity. 
***The scheduler ensures that, for each resource type, the sum of the resource requests of the scheduled Containers is less than the capacity of the node. Note that although actual memory or CPU resource usage on nodes is very low, the scheduler still refuses to place a Pod on a node if the capacity check fails

Mi:
For example, the following represent roughly the same value: 128974848, 129e6, 129M, 123Mi