上一期我们胎教级别的讲解了如何将k8s部署到虚拟机上面，这片能我将主要涵盖了如标题一样的，pod部署，控制器，微服务，集群存储，集群网络和调度，以及集群的认证。
一.k8s的pod部署
1.先来讲解pod是什么东西
pod你可以理解是一个豌豆荚，而容器则是里面的豌豆粒
pod是一个篮子而容器则是里面的鸡蛋
1、一个pod里的容器能有多少资源也取决于这个篮子的大小。
2、label也是贴在篮子上的。
3、IP分配给篮子而不是容器，篮子里面的所有容器共享这个IP。（pod是IP等网络资源的分配的基本单位，这个IP及其对应的network namespace是由pod里的容器共享的；）
4、哪怕只有一个鸡蛋（容器），Kubernetes仍然会给它分配一个篮子。
5、pod里的容器共享network namespace，并通过volume机制共享一部分存储。
Pod运行在节点Node中；
Pod是对容器的封装，是k8s最小的调度单元，也是Kubernetes最重要的基本概念；
2.静态pod（自主式pod）
企业中并不推荐使用此pod，仅供学习和调试方便使用，因为这种静态pod如果批量创建需要大量人工成本不能实现自动部署，滚动更新等，所以这种pod的管理效率低下成本高，且不能与自动化工具连用，健康性差，无法检查。
kubectl get pods
No resources found in default namespace.建立pod
kubectl run qizhiang --image nginxkubectl get pods
NAME READY STATUS RESTARTS AGE
qizhiang 1/1 Running 0 6s
显示详细设置：
kubectl get pods -o wide3.利用控制器管理pod
这种pod属于企业常用的pod工具，具有高可用和高可靠性和扩展性强的特点
自动故障恢复：如果一个 Pod 失败或被删除，控制器会自动创建新的 Pod 来维持期望的副本数量。确保应用始终处于可用状态，减少因单个 Pod 故障导致的服务中断。
健康检查和自愈：可以配置控制器对 Pod 进行健康检查（如存活探针和就绪探针）。如果 Pod 不健康，控制器会采取适当的行动，如重启 Pod 或删除并重新创建它，以保证应用的正常运行。
轻松扩缩容：可以通过简单的命令或配置更改来增加或减少 Pod 的数量，以满足不同的工作负载需求。例如，在高流量期间可以快速扩展以处理更多请求，在低流量期间可以缩容以节省资源。
水平自动扩缩容（HPA）：可以基于自定义指标（如 CPU 利用率、内存使用情况或应用特定的指标）自动调整 Pod 的数量，实现动态的资源分配和成本优化。
滚动更新：对于 Deployment 等控制器，可以执行滚动更新来逐步替换旧版本的 Pod 为新版本，确保应用在更新过程中始终保持可用。可以控制更新的速率和策略，以减少对用户的影响。
回滚：如果更新出现问题，可以轻松回滚到上一个稳定版本，保证应用的稳定性和可靠性。
且具有一致的部署方式，可以通过相同的控制器进行部署，提高效率。
创建pod
kubectl create deployment qizhiang --image nginx为pod扩容
kubectl scale deployment qizhiang --replicas 6为pod缩容
kubectl scale deployment qizhiang --replicas 2用kubectl get pods查看可发现明显不同
4.版本更新
利用控制器建立pod
kubectl create deployment qizhiang --image myapp:v1 --replicas 2暴露端口
kubectl expose deployment qizhiang --port 80 --target-port 80查看服务状态
kubectl get services访问服务
curl 10.110.195.120
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
curl 10.110.195.120
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>查看历史版本
kubectl rollout history deployment qizhiang
deployment.apps/qizhiang
REVISION CHANGE-CAUSE
1 <none>更新控制器镜像版本
kubectl set image deployments/qizhiang myapp=myapp:v2
deployment.apps/qizhiang image updated查看历史版本
kubectl rollout history deployment qizhiang
deployment.apps/qizhiang
REVISION CHANGE-CAUSE
1 <none>
2 <none>
访问测试
curl 10.110.195.120
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>版本回退
kubectl rollout undo deployment qizhiang --to-revision 1
deployment.apps/qizhiang rolled back
curl 10.110.195.120
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>二.控制器
控制器也是管理pod的一种手段
-
自主式pod：pod退出或意外关闭后不会被重新创建
-
控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目
Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod
当建立控制器后，会把期望值写入etcd，k8s中的apiserver检索etcd中我们保存的期望状态，并对比pod的当前状态，如果出现差异代码自驱动立即恢复
我们要介绍几个控制器
ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行
Deployment 一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力
DaemonSet DaemonSet 确保全指定节点上运行一个 Pod 的副本
Job 执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束
1.replicaset
ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行
虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制
生成yml文件
kubectl create deployment replicaset --image myapp:v1 --dry-run=client -o yaml > replicaset.yml查看主要内容
vim replicaset.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: replicaset #指定pod名称，一定小写，如果出现大写报错
spec:
replicas: 2 #指定维护pod数量为2
selector: #指定检测匹配方式
matchLabels: #指定匹配方式为匹配标签
app: myapp #指定匹配的标签为app=myapp
template: #模板，当副本数量不足时，会根据下面的模板创建pod副本
metadata:
labels:
app: myapp
spec:
containers:
- image: myapp:v1
name: myapp
kubectl apply -f replicaset.yml
replicaset.apps/replicaset created
kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
replicaset-l4xnr 1/1 Running 0 96s app=myapp
replicaset-t2s5p 1/1 Running 0 96s app=myapp可以看到该控制器是用标签匹配pod的
kubectl label pod replicaset-l4xnr app=qizhiang --overwrite
pod/replicaset-l4xnr labeled
kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
replicaset-gd5fh 1/1 Running 0 2s app=myapp #新开启的pod
replicaset-l4xnr 1/1 Running 0 3m19s app=timinglee
replicaset-t2s5p 1/1 Running 0 3m19s app=myapp恢复标签之后
kubectl label pod replicaset-example-q2sq9 app-
kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS
replicaset-example-q2sq9 1/1 Running 0 3m14s app=nginx
replicaset-example-th24v 1/1 Running 0 3m14s app=nginx
replicaset-example-w7zpw 1/1 Running 0 3m14s app=nginx
可以看到删除后因为控制副本数量，pod在自我修复
kubectl delete pods replicaset-t2s5p
pod "replicaset-t2s5p" deleted
kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
replicaset-l4xnr 1/1 Running 0 5m43s app=myapp
replicaset-nxmr9 1/1 Running 0 15s app=myapp回收
kubectl delete -f rs-example.yml2.deployment 控制器
-
为了更好的解决服务编排的问题，kubernetes在V1.2版本开始，引入了Deployment控制器。
-
Deployment控制器并不直接管理pod，而是通过管理ReplicaSet来间接管理Pod
-
Deployment管理ReplicaSet，ReplicaSet管理Pod
-
Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法
-
在Deployment中ReplicaSet相当于一个版本
生成yml文件
kubectl create deployment deployment --image myapp:v1 --dry-run=client -o yaml > deployment.yml
vim deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment
spec:
replicas: 4
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- image: myapp:v1
name: myapp创建pod
kubectl apply -f deployment.yml
deployment.apps/deployment created查看pod信息
kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
deployment-5d886954d4-2ckqw 1/1 Running 0 23s app=myapp,pod-template-hash=5d886954d4
deployment-5d886954d4-m8gpd 1/1 Running 0 23s app=myapp,pod-template-hash=5d886954d4
deployment-5d886954d4-s7pws 1/1 Running 0 23s app=myapp,pod-template-hash=5d886954d4
deployment-5d886954d4-wqnvv 1/1 Running 0 23s app=myapp,pod-template-hash=5d886954d4版本迭代
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deployment-5d886954d4-2ckqw 1/1 Running 0 2m40s 10.244.2.14 k8s-node2 <none> <none>
deployment-5d886954d4-m8gpd 1/1 Running 0 2m40s 10.244.1.17 k8s-node1 <none> <none>
deployment-5d886954d4-s7pws 1/1 Running 0 2m40s 10.244.1.16 k8s-node1 <none> <none>
deployment-5d886954d4-wqnvv 1/1 Running 0 2m40s 10.244.2.15 k8s-node2 <none> <none>
查看运行版本后发现为v1
curl 10.244.2.14
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
kubectl describe deployments.apps deployment
Name: deployment
Namespace: default
CreationTimestamp: Sun, 01 Sep 2024 23:19:10 +0800
Labels: <none>
Annotations: deployment.kubernetes.io/revision: 1
Selector: app=myapp
Replicas: 4 desired | 4 updated | 4 total | 4 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge #默认每次更新25%
更新容器运行版本
vim deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment
spec:
minReadySeconds: 5 #最小就绪时间5秒
replicas: 4
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- image: myapp:v2 #更新为版本2
name: myappkubectl apply -f deployment-example.yaml测试效果
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
deployment-7f4786db9c-967fk 1/1 Running 0 10s 10.244.1.26 k8s-node1 <none> <none>
deployment-7f4786db9c-cvb9k 1/1 Running 0 10s 10.244.2.24 k8s-node2 <none> <none>
deployment-7f4786db9c-kgss4 1/1 Running 0 9s 10.244.1.27 k8s-node1 <none> <none>
deployment-7f4786db9c-qts8c 1/1 Running 0 9s 10.244.2.25 k8s-node2 <none> <none>
curl 10.244.1.26
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>更新的过程是重新建立一个版本的RS，新版本的RS会把pod 重建，然后把老版本的RS回收
暂停和回复
在实际生产环境中我们做的变更可能不止一处，当修改了一处后，如果执行变更就直接触发了
我们期望的触发时当我们把所有修改都搞定后一次触发
暂停，避免触发不必要的线上更新
kubectl rollout pause deployment deployment-example
vim deployment-example.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-example
spec:
minReadySeconds: 5
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
replicas: 6
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: nginx
resources:
limits:
cpu: 0.5
memory: 200Mi
requests:
cpu: 0.5
memory: 200Mi
kubectl apply -f deployment-example.yaml
调整副本数，不受影响
kubectl describe pods deployment-7f4786db9c-8jw22
Name: deployment-7f4786db9c-8jw22
Namespace: default
Priority: 0
Service Account: default
Node: k8s-node1/172.25.254.10
Start Time: Mon, 02 Sep 2024 00:27:20 +0800
Labels: app=myapp
pod-template-hash=7f4786db9c
Annotations: <none>
Status: Running
IP: 10.244.1.31
IPs:
IP: 10.244.1.31
Controlled By: ReplicaSet/deployment-7f4786db9c
Containers:
myapp:
Container ID: docker://01ad7216e0a8c2674bf17adcc9b071e9bfb951eb294cafa2b8482bb8b4940c1d
Image: myapp:v2
Image ID: docker-pullable://myapp@sha256:5f4afc8302ade316fc47c99ee1d41f8ba94dbe7e3e7747dd87215a15429b9102
Port: <none>
Host Port: <none>
State: Running
Started: Mon, 02 Sep 2024 00:27:21 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-mfjjp (ro)
Conditions:
Type Status
PodReadyToStartContainers True
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-api-access-mfjjp:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 6m22s default-scheduler Successfully assigned default/deployment-7f4786db9c-8jw22 to k8s-node1
Normal Pulled 6m22s kubelet Container image "myapp:v2" already present on machine
Normal Created 6m21s kubelet Created container myapp
Normal Started 6m21s kubelet Started container myapp
但是更新镜像和修改资源并没有触发更新
kubectl rollout history deployment deployment-example
deployment.apps/deployment-example
REVISION CHANGE-CAUSE
3 <none>
4 <none>恢复后开始触发更新
kubectl rollout resume deployment deployment-examplekubectl rollout history deployment deployment-example
deployment.apps/deployment-example
REVISION CHANGE-CAUSE
3 <none>
4 <none>
5 <none>回收
kubectl delete -f deployment-example.yaml
3.daemonset控制器
DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时， 也会为他们新增一个 Pod ，当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod
DaemonSet 的典型用法：
-
在每个节点上运行集群存储 DaemonSet，例如 glusterd、ceph。
-
在每个节点上运行日志收集 DaemonSet，例如 fluentd、logstash。
-
在每个节点上运行监控 DaemonSet，例如 Prometheus Node Exporter、zabbix agent等
-
一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用
-
一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求
cat daemonset-example.yml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: daemonset-example
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
tolerations: #对于污点节点的容忍
- effect: NoSchedule
operator: Exists
containers:
- name: nginx
image: nginxkubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
daemonset-87h6s 1/1 Running 0 47s 10.244.0.8 k8s-master <none> <none>
daemonset-n4vs4 1/1 Running 0 47s 10.244.2.38 k8s-node2 <none> <none>
daemonset-vhxmq 1/1 Running 0 47s 10.244.1.40 k8s-node1 <none> <none>回收
kubectl delete -f daemonset-example.yml
4.job
Job，主要用于负责批量处理(一次要处理指定数量任务)短暂的一次性(每个任务仅运行一次就结束)任务
Job特点如下：
-
当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量
-
当成功结束的pod达到指定的数量时，Job将完成执行
[root@k8s2 pod]# vim job.yml
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
completions: 6 #一共完成任务数为6
parallelism: 2 #每次并行完成2个
template:
spec:
containers:
- name: pi
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] 计算Π的后2000位
restartPolicy: Never #关闭后不自动重启
backoffLimit: 4 #运行失败后尝试4重新运行
[root@k8s2 pod]# kubectl apply -f job.yml关于重启策略设置的说明：
-
如果指定为OnFailure，则job会在pod出现故障时重启容器
而不是创建pod，failed次数不变
-
如果指定为Never，则job会在pod出现故障时创建新的pod
并且故障pod不会消失，也不会重启，failed次数加1
-
如果指定为Always的话，就意味着一直重启，意味着job任务会重复去执行了
三.微服务
先来依旧讲解什么是微服务
用控制器来完成集群的工作负载，那么应用如何暴漏出去？需要通过微服务暴漏出去后才能被访问
-
Service是一组提供相同服务的Pod对外开放的接口。
-
借助Service，应用可以实现服务发现和负载均衡。
-
service默认只支持4层负载均衡能力，没有7层功能。（可以通过Ingress实现）
1.配置微服务
生成控制文件
kubectl create deployment qizhiang --image myapp:v1 --replicas 2 --dry-run=client -o yaml > qizhiang.yaml
生成微服务yaml追加到已有yaml中
kubectl expose deployment qizhiang --port 80 --target-port 80 --dry-run=client -o yaml >> qizhiang.yaml
kubectl apply -f qizhiang.yaml
deployment.apps/qizhiang created
service/qizhiang createdkubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 19h
qizhiang ClusterIP 10.99.127.134 <none> 80/TCP 16s
微服务默认使用iptables调度
kubectl get services -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 19h <none>
qizhiang ClusterIP 10.99.127.134 <none> 80/TCP 119s app=qizhiang
#集群内部IP 134可以在火墙中查看到策略信息
iptables -t nat -nL
KUBE-SVC-I7WXYK76FWYNTTGM 6 -- 0.0.0.0/0 10.99.127.134 /* default/qizhiang cluster IP */ tcp dpt:802.使用ipvs模式
-
Service 是由 kube-proxy 组件，加上 iptables 来共同实现的
-
kube-proxy 通过 iptables 处理 Service 的过程，需要在宿主机上设置相当多的 iptables 规则，如果宿主机有大量的Pod，不断刷新iptables规则，会消耗大量的CPU资源
-
IPVS模式的service，可以使K8s集群支持更多量级的Pod
下载
yum install ipvsadm –y重启pod，在pod运行时配置文件中采用默认配置，当改变配置文件后已经运行的pod状态不会变化，所以要重启pod
kubectl -n kube-system get pods | awk '/kube-proxy/{system("kubectl -n kube-system delete pods "$1)}'
ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.96.0.1:443 rr
-> 172.25.254.100:6443 Masq 1 0 0
TCP 10.96.0.10:53 rr
-> 10.244.0.2:53 Masq 1 0 0
-> 10.244.0.3:53 Masq 1 0 0
TCP 10.96.0.10:9153 rr
-> 10.244.0.2:9153 Masq 1 0 0
-> 10.244.0.3:9153 Masq 1 0 0
TCP 10.97.59.25:80 rr
-> 10.244.1.17:80 Masq 1 0 0
-> 10.244.2.13:80 Masq 1 0 0
UDP 10.96.0.10:53 rr
-> 10.244.0.2:53 Masq 1 0 0
-> 10.244.0.3:53 Masq 1 0 0
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
