不知此网站枉做男人,重庆建设工程信息网官网查询平台,申办网站流程,wordpress 菜单 文章列表写个笔记#xff0c;后面再完善
部署第一个应用
为什么先实战水平扩缩#xff1f;因为这个最简单#xff0c;首先来部署一个喜闻乐见的nginx
kubectl create deployment web --imagenginx:1.14 --dry-run -o yaml web.yaml
--dry-run表示试运行#xff0c;试一下看… 写个笔记后面再完善
部署第一个应用
为什么先实战水平扩缩因为这个最简单首先来部署一个喜闻乐见的nginx
kubectl create deployment web --imagenginx:1.14 --dry-run -o yaml web.yaml
--dry-run表示试运行试一下看行不行但是不运行-o yaml表示以yaml格式输出 web.yaml表示将输出的内容重定向到web.yaml文件中
这句话可以放心执行了执行之后看看web.yaml文件里面有些啥
apiVersion: apps/v1 # 表示资源版本号为apps/v1
kind: Deployment # 表示这是一个Deployment
metadata: # 一些元数据信息creationTimestamp: nulllabels: # 标签可以随便定义app: webname: web # 这个资源的名字
spec: # 资源的描述或者规格replicas: 1 # 副本数量selector: # 选择器matchLabels: # 需要匹配的标签app: web # 标签的具体键值对strategy: {}template: # 模板。表示Pod的生成规则metadata:creationTimestamp: nulllabels:app: webspec: containers:- image: nginx:1.14 #指定镜像文件name: nginxresources: {}
status: {}
用下面的命令应用web.yamlweb.yaml声明了一个Deployment和一个Pod
kubectl apply -f web.yaml
执行完后以后可以通过以下命令查看Deployment和Pod
kubectl get deploy,po -o wide
结果如下
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
deployment.apps/web 1/1 1 1 2m40s nginx nginx:1.14 appwebNAME READY STATUS RESTARTS AGE IP NODE ...
pod/web-5bb6fd4c98-lg555 1/1 Running 0 2m40s 10.100.255.120 my-node ...
可以看到资源已经建立起来了运行在Worker节点中尝试访问一下Pod的IP
curl 10.100.255.120
有如下nginx的标准返回说明应用已经部署完毕
!DOCTYPE html
html
head
titleWelcome to nginx!/title
...
/html
有没有感觉这一路下来挺麻烦的yaml文件还那么长还不如无脑docker run呢别急在后面扩缩容的时候就可以看到它的威力了当然也可以用最开始的命令来执行kubectl create deployment web --imagenginx:1.14测试可以在生产环境中强烈不建议这么做。
但是现在还不能在外面访问
先要创建一个Service 要访问部署在 Kubernetes 中的应用程序你通常需要使用 Service 对象来公开应用程序以便从外部网络访问。以下是创建一个 Service 来访问你的 web deployment 的一般步骤 创建一个 Service 对象
kubectl create service nodeport web --tcp80:80这将创建一个 NodePort 类型的 Service它将监听节点上的某个端口通常在30000-32767之间并将流量转发到你的 web deployment 的端口80。
获取 Service 的访问端口
kubectl get service web查找 PORT(S) 部分你会看到 Service 的访问端口其中 NodePort 是你可以使用的外部端口。
访问应用程序
现在你可以使用集群的任何节点的 IP 地址和上面步骤中找到的 NodePort 访问你的应用程序。例如如果你的集群节点的 IP 地址是 192.168.1.100NodePort 是 31000你可以在浏览器中输入 http://192.168.1.100:31000 来访问应用程序。
请注意NodePort Service 在生产环境中可能不是最佳选择通常会使用 Ingress 控制器来管理外部访问。但对于测试和学习的目的NodePort 可以用作一种简单的方法来访问应用程序 节点污点
Taint 污点节点不做普通分配调度是节点属性属性值有三个
NoSchedule一定不被调度PreferNoSchedule尽量不被调度也有被调度的几率NoExecute不会调度并且还会驱逐Node已有Pod
也就是说给节点打上污点那么调度的时候就会根据上面的属性来进行调度一般来说Master节点的污点值是NoSchedule查看Master污点值
kubectl describe node my-master | grep Taints
可以看到如下输出
Taints: node-role.kubernetes.io/master:NoSchedule
这表明无论如何Pod都不会被调度到Master节点上也可以用上面弹性伸缩的列子来证明无论副本多少个都是在Worker节点上现在将Master节点上的污点给去掉用下面的命令
kubectl taint node my-master node-role.kubernetes.io/master:NoSchedule-
回显如下说明污点已经去掉
node/my-master untainted
再来扩容一下为了大概率调度到Master节点上可以将副本设置多一点
kubectl scale deploy web --replicas20
在查看Podkubectl get po -o wide
web-5bb6fd4c98-9rrp2 1/1 Running 0 5m19s 10.100.255.108 my-node none ...
web-5bb6fd4c98-fgsfn 1/1 Running 0 5m19s 10.100.0.200 my-master none ...
web-5bb6fd4c98-g7p4w 1/1 Running 0 5m19s 10.100.255.112 my-node none ...
可以看到一部分节点调度到Master上面去了
先缩容将污点加回去用下面的命令再扩容试试看可以发现新增加的节点都在Worker节点上了
kubectl taint node my-master node-role.kubernetes.io/master:NoSchedule 节点标签选择器
首先删除deploykubectl delete deploy web
给master节点打上标签test123_envprod标签就是键值对随便起名儿
kubectl label node my-master test123_envprod
然后在web.yaml中新增nodeSelector声明
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: webname: web
spec: replicas: 10 # 副本改多一点selector: matchLabels:app: web strategy: {}template: metadata:labels:app: webspec:containers:- image: nginx:1.14name: nginx# 新增的内容nodeSelector:test123_env: prod
status: {}
最后执行理论上所有Pod都应该被调度到Master节点上但是发现所有的Pod都被挂起了没有被调度
web-6897865b86-sp6fh 0/1 Pending 0 30s none none none none
web-6897865b86-vkcx2 0/1 Pending 0 30s none none none none
web-6897865b86-wvdk6 0/1 Pending 0 30s none none none none
这是什么原因呢这是污点在作祟别忘记了Master节点的污点值默认是NoSchedule不允许被调度的查看一下Master节点的污点值
[rootmy-master ~]# kubectl describe node my-master | grep Taints
Taints: node-role.kubernetes.io/master:NoSchedule
果然是NoSchedule先去掉污点值
kubectl taint node my-master node-role.kubernetes.io/master:NoSchedule-
机器突然有点卡这应该是在调度Pod了查看一下果不其然节点都被调度到了Master上
web-6897865b86-sp6fh 1/1 Running 0 4m2s 10.100.0.208 my-master none ...
web-6897865b86-vkcx2 1/1 Running 0 4m2s 10.100.0.209 my-master none ...
web-6897865b86-wvdk6 1/1 Running 0 4m2s 10.100.0.213 my-master none ...
这里还可以得出一个结论在Pod被调度的时候节点污点值的优先级是高于节点标签的
最后还原现场
# 删除deploy
kubectl delete deploy web# 删掉标签
kubectl label node my-master test123_env-# 恢复污点
kubectl taint node my-master node-role.kubernetes.io/master:NoSchedule 节点亲和性
亲和性和节点选择器类似多了操作符表达式In、NotIn、Exists、Gt、Lt、DoesNotExists此处就不再演示了感兴趣的同学自行尝试一下
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: webname: web
spec: replicas: 10 # 副本改多一点selector: matchLabels:app: web strategy: {}template: metadata:labels:app: webspec:containers:- image: nginx:1.14name: nginx# 新增的内容affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: test123_envoperator: Invalues:- dev- testpreferreDuringSchedulingIgnoredDuringExecution:- weight: 1preference:- matchExpressions:- key: groupoperator: Invalues:- ttttest
status: {}
上面的亲和性表示如下含义
requiredDuringSchedulingIgnoredDuringExecution硬亲和test123_env等于dev或者test必须满足preferreDuringSchedulingIgnoredDuringExecution软亲和group等于ttttest非必须满足
K8S搞这么多策略有啥用呢又是节点污点、节点标签、Pod调度策略之类的目的当然是提供最大的灵活性最终提高整体资源利用率这就是自动装箱
这里的 affinity 部分用于定义容器在调度到节点时的偏好设置。具体来说这个配置包括两部分 requiredDuringSchedulingIgnoredDuringExecution这是一个必需的亲和性规则它要求容器只能被调度到满足指定条件的节点上。在这个示例中它要求节点的 test123_env 标签的值必须是 dev 或 test否则容器将不会被调度到这些节点。 preferreDuringSchedulingIgnoredDuringExecution这是一个偏好的亲和性规则它定义了容器倾向于被调度到满足指定条件的节点上。在这个示例中它定义了一个权重为1的偏好规则要求节点的 group 标签的值应为 ttttest以增加容器被调度到这些节点的可能性。这并不是一个硬性要求只是一个偏好设置。
总之这些亲和性设置帮助 Kubernetes 调度器在将 Pod 调度到节点时考虑节点的标签和属性以满足或偏好某些条件。这有助于优化应用程序的性能和资源利用。
