kubernetes

调度器：

https://kubernetes.io/zh/docs/tasks/administer-cluster/topology-manager/

 

Pod 拓扑分布约束

API

pod.spec.topologySpreadConstraints 字段定义如下所示：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  topologySpreadConstraints:
    - maxSkew: <integer>
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>

节点亲和性与节点选择器的相互作用 

如果 Pod 定义了 spec.nodeSelector 或 spec.affinity.nodeAffinity，调度器将从倾斜计算中跳过不匹配的节点。

affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: zone
            operator: NotIn
            values:
            - zoneC

 

污点和容忍，taint，toleration，如果用户需要在特定硬件上部署应用程序，或者想要将一组节点专用于特定用户，则此功能很有用。

 

 

 

健康检查

kubulet进行readyness，liveness，检测，有启动吗？

用户可以通过定义要由kubelet代理运行的探测，来检查Kubernetes中Pod或应用程序的运行状况。用户可以定义就绪性、活动性和启动探测，如下所示：

• 准备就绪—确定容器是否可以接收请求。如果失败，则从将流量定向到Pod的所有端点中删除Pod IP地址。
• 活动性—确定是否需要重新启动容器。失败意味着容器被终止并重新启动。
• 启动—确定容器中的应用程序是否已启动。在失败的情况下，容器将被终止并重新启动。

用户可以使用超时、重试次数、最小成功或失败阈值以及延迟的运行时间自定义探测。

--------------------------------------------------------------------------------------------------------------------------------------

扩缩副本

/usr/local/bin/kubectl scale --replicas=0 deployment/logstash  -n namespace

 

 

 

命令：kubectl set image deployment/nginx-deployment nginx=nginx：1.9.2

由于nginx：1.9.2不存在，发布过程卡主我们使用Ctrl-C中止

 

用kubectl rollout status 命令查看Deployment的更新过程

kubectl rollout status deployment/nginx-deployment

 

kubectl rollout history查看这个Deployment的历史记录

kubectl rollout history deployment/nginx-deployment

 

查看特定版本的详情信息

kubectl rollout history deployment/nginx-deployment --revision=3

 

 

回滚到上一个版本

kubectl rollout undo deployment/nginx-deployment

回滚到特定版本

kubectl rollout undo deployment/nginx-de

 

 

健康检查：

 kubectl get cs

 kubectl get --raw='/readyz'

 

 

 

 

https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

 

google  yum 用不了，用阿里的：

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
        http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

 

 

关闭分区：

swapoff -a

 

 

安装docker

然后，（这个要做 是docker 的cgroup用systemd 不然kubelet起不来）

2. 配置 Docker 守护程序，尤其是使用 systemd 来管理容器的 cgroup。

   sudo mkdir /etc/docker
   cat <<EOF | sudo tee /etc/docker/daemon.json
   {
     "exec-opts": ["native.cgroupdriver=systemd"],
     "log-driver": "json-file",
     "log-opts": {
       "max-size": "100m"
     },
     "storage-driver": "overlay2"
   }
   EOF
   

   说明：

   对于运行 Linux 内核版本 4.0 或更高版本，或使用 3.10.0-51 及更高版本的 RHEL 或 CentOS 的系统，overlay2是首选的存储驱动程序。

3. 重新启动 Docker 并在启动时启用：

   sudo systemctl enable docker
   sudo systemctl daemon-reload
   sudo systemctl restart docker
   
   
   
   
   

   kubeadm init --control-plane-endpoint 192.168.102.153 --image-repository registry.aliyuncs.com/google_containers --pod-network-cidr=10.244.0.0/16

   初始化命令  ，--image-repository  这个参数重点  设定国内镜像

   -pod-network-cidr  指定网段  不然装flannel后 pod一直重启。如果忘记了，也可以后期编辑文件/etc/kubernetes/manifests/kube-controller-manager.yaml，加入

   - --allocate-node-cidrs=true
   - --cluster-cidr=10.244.0.0/16

    

    

   kubeadm init 有问题，

   kubeadm reset  可以重置
   
   
   
   

   Your Kubernetes control-plane has initialized successfully!

   To start using your cluster, you need to run the following as a regular user:

   mkdir -p $HOME/.kube
   sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
   sudo chown $(id -u):$(id -g) $HOME/.kube/config

   Alternatively, if you are the root user, you can run:

   export KUBECONFIG=/etc/kubernetes/admin.conf

   You should now deploy a pod network to the cluster.
   Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
   https://kubernetes.io/docs/concepts/cluster-administration/addons/

   You can now join any number of control-plane nodes by copying certificate authorities
   and service account keys on each node and then running the following as root:

   kubeadm join 192.16:6443 --token 9azuxb.larxid04481iuk9m \
   --discovery-token-ca-cert-hash sha256:f8608e6baf030032c288ce2f4e95a230485d7c465c82a481916a5acffcf9241e \
   --control-plane

   Then you can join any number of worker nodes by running the following on each as root:

   kubeadm join 192.1:6443 --token 9azuxb.larxid04481iuk9m \
   --discovery-token-ca-cert-hash sha256:f8608e6baf030032c288ce2f4e95a230485d7c465c82a481916a5acffcf9241e

    

   用flannel的网

    kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

    

   --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

   常用操作：

   configmap 和 secret 都可以配合环境变量使用，用环境变量，命令行参数或者配置文件给到程序

   1，echo -n 'admin' > ./username.txt
   echo -n '1f2d1e2e67df' > ./password.txt

   你可以在本地计算机上，将用户名存储在文件 ./username.txt 中，将密码存储在文件 ./password.txt 中。-n 标志确保生成的文件在文本末尾不包含额外的换行符。 
   这一点很重要，因为当 kubectl 读取文件并将内容编码为 base64 字符串时，多余的换行符也会被编码。 
   
   2，从文件创建secret
   

   kubectl create secret generic db-user-pass \
     --from-file=username=./username.txt \
     --from-file=password=./password.txt
   或者直接命令行创建：

   kubectl create secret generic db-user-pass \
     --from-literal=username=devuser \
     --from-literal=password='S!B\*d$zDsb='

   输出类似于：

   secret/db-user-pass created

   
   
   3，查看secret

   kubectl get secret db-user-pass -o jsonpath='{.data}'
   
   

   输出类似于：

   {"password":"MWYyZDFlMmU2N2Rm","username":"YWRtaW4="}
   解码

   echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
   
   

   输出类似于：

   1f2d1e2e67df
   
   4，删除secret

   删除创建的 Secret：

   kubectl delete secret db-user-pass
   
   kubectl 可以有create delete edit get describe 增删改查等动作。本质都是对api server 做restful 的http请求
   
   5，secret配置文件：
   https://kubernetes.io/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/

    
   ---------------------------------------------------------------------------------------------------------------------------------------------
   常用命令：
   
   

   命令手册：https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get
   	---------------------------------------------------------------------------------------------
   	yaml配置文件检查：
   	promtool which comes with Prometheus has a check config command. Let's download Prometheus and create an invalid config:
   	wget https://github.com/prometheus/prometheus/releases/download/v2.5.0/prometheus-2.5.0.linux-amd64.tar.gz
   	tar -xzf prometheus-*.tar.gz
   	cd prometheus-*
   	cat >prometheus.yml <<'EOF'
   	scrape_configs:
   	- job_name: prometehus
   	static_configs:
   	- targets: ['localhost:9090']
   	EOF
   	If you now check the configuration, you'll see an error:
   	./promtool check config prometheus.yml
   	Checking prometheus.yml
   	FAILED: parsing YAML file prometheus.yml: yaml: unmarshal errors:
   	line 3: field static_configs not found in type config.plain
   	and the exit code will be 1, indicating failure.
   	If you fix the last two lines to be correctly indented and check the config again it will now pass:
   	./promtool check config prometheus.yml
   	Checking prometheus.yml
   	SUCCESS: 0 rule files found
   	and the exit code will be 0.
   	This sort of feature isn't limited to Prometheus, the Alertmanager's amtool has a similar feature too.
   	--------------------------------------------------------------------------------------------
   	kubectl config
   	查看当前cluster集群环境
   	kubectl config current-context
   	查看configfile
   	kubectl config view
   	查看全部上下文
   	kubectl config get-contexts
   	切换上下文
   	kubectl config use-context
   	指定config
   	kubectl --kubeconfig=kube/config get ingress
   	查看service：
   	kubectl --kubeconfig=kube/config describe services xxx-service
   	删除pod
   	kubectl delete -f propod.yaml
   	kubectl get pods
   	获取某个节点上的所有pod：
   	kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=
   	describe可以查看每一资源的详细创建信息：
   	kubectl --kubeconfig= describe pvc prometheus
   	kubectl describe pod pod-name -o wide
   	查看yaml
   	kubectl --kubeconfig=kube/config get pod prom -n namespace -o yaml
   	端口代理：
   	kubectl --kubeconfig=kube/config port-forward prometheus-75d9c55b77-qqs48 --address 0.0.0.0 8080:9090 -n kube-ops
   	查看pod日志
   	kubectl logs pod-name (-n namespace-name)
   	指定容器执行命令
   	kubectl exec pod-name -c container-name useing-command
   	kubectl exec -it pod-name -n namespace-name bash(sh or /bin/sh or /bin/bash)
   	查看yaml
   	kubectl get pod -n namespace-name -o yaml
   	-------------------------------------------------------------------------------------------------
   	configmap:
   	基于文件创建：
   	将 ConfigMap 数据添加到一个卷中
   	如基于文件创建 ConfigMap 中所述，当你使用 --from-file 创建 ConfigMap 时，文件名成为存储在 ConfigMap 的 data 部分中的键， 文件内容成为键对应的值。
   	本节中的示例引用了一个名为 special-config 的 ConfigMap，如下所示：
   	configmap/configmap-multikeys.yaml Copy configmap/configmap-multikeys.yaml to clipboard
   	apiVersion: v1
   	kind: ConfigMap
   	metadata:
   	name: special-config
   	namespace: default
   	data:
   	SPECIAL_LEVEL: very
   	SPECIAL_TYPE: charm
   	创建 ConfigMap:
   	kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
   	使用存储在 ConfigMap 中的数据填充数据卷
   	在 Pod 规约的 volumes 部分下添加 ConfigMap 名称。 这会将 ConfigMap 数据添加到指定为 volumeMounts.mountPath 的目录（在本例中为 /etc/config）。 command 部分引用存储在 ConfigMap 中的 special.level。
   	pods/pod-configmap-volume.yaml Copy pods/pod-configmap-volume.yaml to clipboard
   	apiVersion: v1
   	kind: Pod
   	metadata:
   	name: dapi-test-pod
   	spec:
   	containers:
   	- name: test-container
   	image: k8s.gcr.io/busybox
   	command: [ "/bin/sh", "-c", "ls /etc/config/" ]
   	volumeMounts:
   	- name: config-volume
   	mountPath: /etc/config
   	volumes:
   	- name: config-volume
   	configMap:
   	# Provide the name of the ConfigMap containing the files you want
   	# to add to the container
   	name: special-config
   	restartPolicy: Never
   	创建 Pod:
   	kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml
   	Pod 运行时，命令 ls /etc/config/ 产生下面的输出：
   	SPECIAL_LEVEL
   	SPECIAL_TYPE
   	注意： 如果在 /etc/config/ 目录中有一些文件，它们将被删除。
   	----------------------------------------------------------------------------------------------
   	sa:
   	当你创建一个Pod并没有指定一个service account，它将自动的为Pod在相同的namespace中分配default service account
   	kubectl get pods/podname -o yaml 可以查看
   	serviceAccount: default
   	serviceAccountName: default
   	Pod可以使用自动挂载的service account凭证来获取访问API的权限
   	-------------------------------------------------------------------------------------------------------------------
   	监控报警
   	JobDown
   	对应Prometheus指标收集的4个Job、分别为kube-state-metrics、kube-node-exporter、kube-node-kubelet、kube-node-cadvisor，一旦哪个Job有问题，则会进行告警。
   	PodDown
   	当处于Running状态的pod停止时，则会进行告警。
   	PodReady
   	在Pod重新调度后，虽然Pod处于Running状态，由于此时正在重启，Ready为0，只有当readiness探针探测正常后，Ready为1，才会正式接受请求；因此Ready长时间为0时，说明Pod启动有问题，需要进行告警。
   	PodRestart
   	当Pod健康检查不成功，Pod会进行不断的重启，一旦超过一定的次数，则说明Pod有问题，此时需要进行告警。
   	pod状态：
   	Pending， Running ， Succeeded ， Failed，Unknown
   	A given Pod (as defined by a UID) is never "rescheduled" to a different node; instead, that Pod can be replaced by a new,
   	near-identical Pod, with even the same name if desired, but with a different UID.
   	容器状态：
   	There are three possible container states:
   	Waiting, Running, and Terminated.
   	waiting，（进入running后容器过程：initc，poststart ，readyness，liveness，prestop），terminated
   	the terminated state have five reason : reason="Completed"，reason="ContainerCannotRun，reason="DeadlineExceeded"， reason="Error"，reason="OOMKilled"
   	pod条件：
   	PodScheduled: the Pod has been scheduled to a node.
   	ContainersReady: all containers in the Pod are ready.
   	Initialized: all init containers have started successfully.
   	Ready: the Pod is able to serve requests and should be added to the load balancing pools of all matching Services.