Kubernetes学习(011~028)

011、012、DaemonSet典型应用

DaemonSet在每个Node上最多只能运行一个副本。
应用场景:
在集群的每个节点上运行存储Daemon
在每个节点上运行日志收集Daemon
在每个节点上运行监控Daemon


其实k8s自己就在用DaemonSet运行系统组件。
DaemonSet kube-flannel-ds和kube-proxy分别负责在每个节点上运行flannel和kube-proxy组件。
kubectl get daemonset --namespace=kube-system
kubectl get pod --namespace=kube-system -o wide


kube-proxy的YAML无法拿到,可用命令查看其配置
kubect edit daemonset kube-proxy --namespace=kube-system


每个当前运行的资源都可以通过 kubectl edit 查看其配置和运行状态:
kubectl edit deployment nginx-deployment

kubectl apply -f node_exporter.yml
kubectl get pod -o wide
部署成功,k8s-node1和k8s-node2上分别运行了一个node exporter Pod。

014、用k8s运行一次性任务

工作类容器是一次性任务。
Deployment、ReplicaSet和DaemonSet都用于管理服务类容器。
对于工作类容器,用Job。


kubectl apply -f myjob.yml
kubectl get job
kubectl get pod
kubectl get pod --show-all # --show-all才能查看Completed状态的pod
kubectl logs myjob-nfkxk # 查看Pod的标准输出

015、Job失败了怎么办?

在myjob.yml中故意加入一个错误。
kubectl apply -f myjob.yml
kubectl get job # SUCCESSFUL为0
kubectl get pod --show-all # 有很多个Pod,状态为ContainerCannotRun
kubectl describe pod myjob-rbs1x # 查看某个Pod的启动日志,显示没有可执行程序


注意Never和OnFailure的区别,OnFailure会让容器失败后自动重启。

016、并行执行Job

同时运行多个Pod,提高Job的执行效率。
通过parallelism设置。通过 completions 设置 Job 成功完成 Pod 的总数。


启动了两个Pod,而且AGE相同,可见是并行运行的。
kubectl apply -f myjob.yml
kubectl get job
kubectl get pod --show-all -o wide


k8s的CronJob可以定时执行Job。
systemctl restart kubelet.service
kubectl api-versions
kubectl apply -f cronjob.yml
kubectl get cronjob
kubectl get jobs
kubectl get pod --show-all
kubectl logs hello-1505181720-lf350

018、通过Service访问Pod

每个Pod都有自己的IP地址。
当controller用新Pod替代发生故障的Pod时,新Pod会分配到新的IP地址。
那客户端如何找到并访问这个服务呢?Service


Service从逻辑上代表了一组Pod,具体是哪些Pod则是由label来挑选。
Service有自己IP,而且这个IP是不变的。
客户端只需要访问Service的IP。


启动三个Pod,label是run: httpd,Service将会用这个label来挑选Pod
kubectl apply -f httpd.yml
kubectl get pod -o wide
Pod分配了各自的IP,这些IP只能被k8s cluster中的容器和节点访问。
curl 10.244.4.5
curl 10.244.5.4
创建Service。selector指明挑选那些label为run: httpd的Pod作为Service的后端
kubectl apply -f httpd-svc.yml
kubectl get service
httpd-svc分配到一个CLUSTER-IP,通过该IP可以访问后端的httpd Pod。
curl 10.99.229.179:8080


查看httpd-svc与Pod的对应关系(输出结果中,看Endpoints)
kubectl describe service httpd-svc

019、Service IP管理

Service Cluster IP是一个虚拟IP,由k8s节点上的iptables规则管理。
iptables-save


如果Cluster内的Pod要访问httpd-svc(源地址来自 10.244.0.0/16),则允许
其他源地址访问httpd-svc,跳转到规则KUBE-SVC0RL3JAE4GN
KUBE-SVC0RL3JAE4GN规则是将请求分别转发到后端的三个Pod。


结论:
iptables将访问Service的流量转发到后端Pod,而且使用类似轮询的负载均衡策略。
补充:
Cluster的每一个节点都配置了相同的iptables规则,这样就确保了整个Cluster都能够通过Service的Cluster IP访问Service。
除了直接通过Cluster IP访问Service,DNS是更加便捷的方式。

020、DNS访问Service

每当有新的Service被创建,kube-dns会添加该Service的DNS记录。
Cluster中的Pod可以通过<SERVICE_NAME>.<NAEMSPACE_NAME>访问Service。
kubectl get deployment --namespace=kube-system


如:用httpd-svc.default访问Service httpd-svc
kubectl run busybox --rm -ti --image=busybox /bin/sh
wget httpd-svc.default:8080
另外这个Pod与httpd-svc同属于defalut namespace,可以省略default直接用httpd-svc访问Service
wget httpd-svc:8080


查看httpd-svc的DNS的信息
nslookup httpd-svc


DNS服务器时kube-dns.kube-system.svc.cluster.local
这实际上是kube-dns组件,它本身是部署在kube-system namespace中的一个Service。
httpd-svc.default.svc.cluster.local是httpd-svc的完整域名。
如果要访问其他namespace中的Service,就必须带上namespace了。
kubectl get namespace


kube-public中部署Service http2-svc:
kubectl apply -f httpd2.yml
kubectl get service --namespace=kube-public
用创建的临时容器访问http2-svc:
kubectl run busybox --rm -ti --image=busybox /bin/sh
wget http2-svc.kube-public:8080


k8s集群内容可以通过Cluster IP和DNS访问Service,那么集群外部如何访问呢?

021、外网如何访问Service?

k8s默认提供多种Service,默认是ClusterIP。
ClusterIP
Service通过Cluster内部的IP对外提供服务
只有Cluster内的节点和Pod可访问
NodePort
Service通过Cluster节点的静态端口对外提供服务
Cluster外部可以通过:访问Service
LoadBalancer
Service利用cloud provider特有的load balancer对外提供服务
cloud provider负责将load balancer的流量导向Service


type: NodePort
kubectl apply -f httpd-svc.yml
kubectl get service httpd-svc # 看EXTERNAL-IP和PORT(S)
netstat -an|grep 32312
k8s依然会给它分配一个ClusterIP。
EXTERNAL-IP为nodes,表示可通过Cluster每个节点自身的IP访问Service。


通过三个节点IP+32312端口都能够访问httpd-svc
curl 192.168.56.105:32312
curl 192.168.56.106:32312
curl 192.168.56.107:32312

访问当前节点32312端口的请求会应用规则KUBE-SVC-RL3JAE,其作用就是负载均衡到每一个Pod。
NodePort默认是随机选择。

022、Rolling Update

滚动更新的最大好处是零停机,整个更新过程始终有副本在运行,从而保证了业务的连续性。
kubectl apply -f httpd.yml
kubectl get deployment httpd -o wide
kubectl get replicaset -o wide
kubectl get pod
kubectl describe deployment httpd
Kubernetes 提供了两个参数 maxSurge 和 maxUnavailable 来精细控制 Pod 的替换数量


每次更新都会记录当前的配置,保存为一个revision(版次)
–record的作用是将当前命令记录到revision记录中。
kubectl apply -f httpd.v1.yml --record


查看revision历史记录:
kubectl rollout history deployment httpd


回滚到某个版本:
kubectl rollout undo deployment httpd --to-revision=1
revision历史记录也会发生相应变化,revsion 1变成了revision 4:
kubectl rollout history deployment httpd

024、Health Check

自愈的默认实现方式是自动重启发生故障的容器。
除此之外,用户还可以利用Liveness和Readiness探测机制设置更精细的健康检查。
进而实现:
a、零停机部署
b、避免部署无效的镜像
c、更加安全的滚动升级


Liveness探测让用户可以自定义判断容器是否健康的条件。
如果探测失败,k8s就会重启容器。


Readiness探测是告诉k8s什么时候可以将容器加入到Service负载均衡池中,对外提供服务。


在Scale Up中使用Health Check。
对于生产环境中重要的应用都建议配置Health Check,保证处理客户请求的容器都是准备就绪的Service backend。
如果正确配置了 Health Check,新副本只有通过了 Readiness 探测,才会被添加到 Service;如果没有通过探测,现有副本不会被全部替换,业务仍然正常进行。

发布了5 篇原创文章 · 获赞 0 · 访问量 174
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览