Kubernetes控制器DaemonSet
介绍DaemonSet控制器
1官网：https://kubernetes.io/zh/docs/concepts/workloads/controllers/daemonset/
通过该控制器的名称我们可以看出它的用法：Daemon，就是用来部署守护进程的，DaemonSet用于在每个 Kubernetes 节点中将守护进程的副本作为后台进程运行，说白了就是在每个节点部署一个 Pod副本，当节点加入到 Kubernetes 集群中，Pod 会被调度到该节点上运行，当节点从集群只能够被移除后，该节点上的这个 Pod 也会被移除，当然，如果我们删除 DaemonSet，所有和这个对象相关的 Pods都会被删除。
应用场景：
集群存储守护程序，如 glusterd、ceph 要部署在每个节点上以提供持久性存储；
节点监控守护进程，如 Prometheus 监控集群，可以在每个节点上运行一个 node-exporter 进程来收集监控节点的信息；
日志收集守护程序，如 fluentd 或 logsta ...
Node节点亲和性调度
调度亲和性给Pod调度到指定节点调度模式：nodeSelector & nodeAffinity
比如将有大量磁盘 I/O 的 Pod 部署到配置了 SSD 的 Node；或者 Pod 需要 GPU，需要运行在配置了 GPU 的节点上。这时就可以使用标签来运行到指定的Node上；
nodeNamenodeName：指定节点名称，用于将Pod调度到指定的Node上；
注意：不经过调度器，前面设置的污点对这个参数无效，相当于走后门；
应用场景：
当Scheduler组件Down掉了，无法进行Pod调度，就可以使用nodeName来调度Pod
12345678910111213141516[root@pool1 data]# vi nodeName-nginx.yaml apiVersion: v1kind: Podmetadata: name: nodename-nginxspec: containers: - name: nodename-nginx image: nginx nodeName: pool3[root@pool1 data]# kubectl a ...
Taint污点及污点容忍
Taint（污点）Taints：避免Pod调度到特定Node上
应用场景：
专用节点，例如配备了特殊硬件的节点
基于Taint的驱逐
设置污点：
123456789101112# 用法：kubectl taint node {node_name} key=value:[effect]其[effect]可取值：* NoSchedule：一定不能被调度* PreferNoSchedule：尽量不要调度* Noexecute：不仅不会调度，还会驱逐Node上已有的Pod# 示例：kubectl taint node node1 node-role.kubernetes.io/master="":NoSchedule[root@pool1 data]# kubectl describe node pool2 | grep TaintsTaints: disktype=ssd:NoSchedule
删除污点：
12kubectl taint node [node_name] key:[effect]-例：kubectl tain ...
Pod亲和性 And Pod反亲和性
Pod 亲和性Pod 亲和性（podAffinity）主要解决 Pod 可以和哪些 Pod 部署在同一个拓扑域中的问题（其中拓扑域用主机标签实现，可以是单个主机，也可以是多个主机组成的 cluster、zone 等等），而 Pod 反亲和性主要是解决 Pod 不能和哪些 Pod 部署在同一个拓扑域中的问题，它们都是处理的 Pod 与 Pod 之间的关系，比如一个 Pod 在一个节点上了，那么我这个也得在这个节点，或者你这个 Pod 在节点上了，那么我就不想和你待在同一个节点上。
由于我们这里只有一个集群，并没有区域或者机房的概念，所以我们这里直接使用主机名来作为拓扑域，把 Pod 创建在同一个主机上面。
1234567$ kubectl get nodes --show-labelsNAME STATUS ROLES AGE VERSION LABELSydzs-master Ready master 55d v1.16.2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/ ...
kubeadm修改ipvs转发模式
kubeadm方式修饰ipvs模式123456789101112131415161718192021222324252627282930313233343536[root@pool1 k8s_yaml]# kubectl edit configmap kube-proxy -n kube-system…… mode: "ipvs"……configmap/kube-proxy edited[root@pool1 k8s_yaml]# kubectl get pods -n kube-system -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESkube-proxy-l5v69 1/1 Running 5 7d6h 172.16.1.22 ...
Ingress HTTP代理访问
有了NodePort为什么用Ingress？NodePort得缺点：
是一个端口只能一个服务使用，端口需提前规划
只支持四成负载均衡
Ingrass Controller是什么？Ingress管理得负载均衡器，为集群提供全局得负载均衡能力；
Ingress是什么？Ingress公开了从集群外部到集群内部服务得http和https路由，流量路由有Ingress资源上定义的规则控制；
转发流程图：
Ingress使用流程：1、部署Ingress Controller
2、部署Ingress Pod规则
注：如果不同命名空间得SVC想互相调用，需要在SVC后面加个”.{namespace_name}”
ingress两种转发模式1、ingress部署完成之后需要部署svc对ingress端口进行暴露
user -> svc(nodeport) -> ingress controller pod -> 节点Pod
2、添加hostNetwork将ingress端口应用到物理机中
user -> ingress controller po ...
部署企业级Harbor镜像仓库
安装docker离线部署
1234[root@harbor-server data]# python InstallDocker.py Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /etc/systemd/system/docker.service.Docker Version as follows：Docker version 18.06.1-ce, build e68fc7a
导入docker-compose执行文件12[root@harbor-server data]# chmod 777 docker-compose [root@harbor-server data]# mv docker-compose /usr/bin/
导入harbor安装包1234[root@harbor-server data]# tar zxf harbor-offline-installer-v2.3.1.tgz[root@harbor-server docker]# cd h ...
离线部署Docker脚本
脚本使用方式：将脚本拷贝到服务器中，并且此脚本目录下有docker的tar包，不需要修改脚本文件，直接执行即可！
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758#!/bin/python# -*- coding: utf-8 -*-import osdef install(): ################################## # version = 'docker-19.03.9.tgz' version = os.popen('ls . | grep ^docker | grep tgz$').read().replace('\n', '') ################################## os.system('tar xf ' ...
应用程序配置文件存储：ConfigMap
应用程序配置文件存储：ConfigMap创建Confirmap后，数据是存储在K8s中etcd，然后通过创建Pod时引用该数据；
ConfigMap演示：创建ConfigMap1234567891011121314151617[root@pool1 k8s_yaml]# vi configmap-config.yaml apiVersion: v1kind: ConfigMapmetadata: name: game-demodata: abc: "1" # 定义变量，用于Pod读取 game.properties: | # 挂载到Pod中得文件名# 文件内容如下 enemy.types=aliens,monsters player.maximum-lives=5[root@pool1 k8s_yaml]# kubectl apply -f configmap-config.yaml [root@pool1 k8s_yaml]# kubectl get cmNAME DATA AGEgame-demo ...
Kubernetes使用labels控制Pod运行位置
默认配置下，Scheduler 会将 Pod 调度到所有可用的 Node。不过有些情况我们希望将 Pod 部署到指定的 Node，比如将有大量磁盘 I/O 的 Pod 部署到配置了 SSD 的 Node；或者 Pod 需要 GPU，需要运行在配置了 GPU 的节点上。
Kubernetes是通过label来实现这个功能的，同之前的docker swarm集群的label是一样的，通过对节点进行label的设置，将Pod运行的指定的label节点上。
label是key-value对，各种资源都可以设置label，灵活添加各种自定义属性。
贴签示例将node2节点的label设置为disktype=ssd
添加标签12[root@pool1 yaml]# kubectl label nodes pool2 disktype=ssdnode/pool2 labeled
12345[root@pool1 yaml]# kubectl get node --show-labelsNAME STATUS ROLES AGE VERSION LA ...
