笔记
概念
Pod是脆弱的,但应用是健壮的。
kubelet运行在Cluster所有节点上,负责启动Pod和容器。kubeadm用于初始化Cluster。kubectl是k8s命令行工具。通过kubectl可以部署和管理应用,查看各种资源,创建、删除和更新各种组件。
Pending、ContainerCreating、ImagePullBackOff都表明Pod没有就绪,Running才是就绪状态。
k8s的系统组件都被放到kube-system namespace中。
kubelet是唯一没有以容器形式运行的k8s组件,它在Ubuntu中通过Systemd服务运行。
出于安全考虑,默认配置下k8s不会将Pod调度到Master节点。如果希望将k8s-master也当作Node使用,可执行如下命令:kubectl taint node <k8s-node> node-role.kubernetes.io/master-
如果要恢复Master Only状态,执行如下命令:kubectl taint node <k8s-node> node-role.kubernetes.io/master="":NoSchedule
默认配置下,Scheduler会将Pod调度到所有可用的Node。不过有些情况希望将Pod部署到指定的Node,如将有大量磁盘I/O的Pod部署到配置SSD的Node;或Pod需要GPU,需要运行在配置GPU的节点上。k8s是通过label来实现这个功能的。
设置label:kubectl label node <k8s-node> disktype=ssd
查看节点的label:kubectl get node --show-labels
然后可以编辑 yml 文件设置nodeSelector:disktype:ssd
删除label,-
即删除的意思:kubectl label node <k8s-node> disktype-
删除label后,除非在yml
中删除nodeSelector设置,并执行kubectl apply
命令重新部署,否则删除label不会生效。
Service
Service从逻辑上代表一组Pod,具体是哪些Pod则是由label来挑选的。Service有自己的不变的IP,客户端只需要访问Service的IP,k8s则负责建立和维护Service与Pod的映射关系。无论后端Pod如何变化,对客户端没有任何影响,因为Service没有变。
Cluster IP是一个虚拟IP,是由k8s节点上的iptables规则管理的。可以通过iptables-save命令打印出当前节点的iptables规则。Cluster的每一个节点都配置了相同的iptables规则,这样就确保了整个Cluster都能够通过Service的Cluster IP访问Service。
除可以通过Cluster IP访问Service,k8s还提供更为方便的DNS访问。k8s部署时会默认安装kube-dns组件,每当有新的Service被创建,kube-dns会添加该Service的DNS记录。Cluster中的Pod可以通过<SERVICE_NAME>.<NAMESPACE_NAME>
访问Service。如果在同一个namespace,则可以省略.<NAMESPACE_NAME>
。
DNS服务器是kube-dns.kube-system.svc.cluster.local
,这实际上就是kube-dns组件,它本身是部署在kube-system namespace中的一个Service。
用nslookup查看httpd-svc的DNS信息。
除了Cluster内部可以访问Service,很多情况下也希望应用的Service能够暴露给Cluster外部。k8s提供多种类型的Service,默认是ClusterIP:
- ClusterIP:Service通过Cluster内部的IP对外提供服务,只有Cluster内的节点和Pod可访问,这是默认的Service类型
- NodePort:Service通过Cluster节点的静态端口对外提供服务。Cluster外部可以通过
<NodeIP>:<NodePort>
访问Service - LoadBalancer:Service利用cloud provider特有的load balancer对外提供服务,cloud provider负责将load balancer的流量导向Service。目前支持的cloud provider有GCP、AWS、Azure等。
DaemonSet
典型应用场景:
- 在集群的每个节点上运行存储Daemon,如glusterd或ceph
- 在每个节点上运行日志收集Daemon,如flunentd或logstash
- 在每个节点上运行监控Daemon,如Prometheus Node Exporter或collectd
Job Pod执行完容器已经退出,需要用--show-all
才能查看Completed状态的Pod。
同时运行多个Pod,提高Job的执行效率。这个可以通过parallelism
设置。
completions设置Job成功完成Pod的总数。
spec:
completions: 6
parallelism: 2
配置解读:每次运行两个Pod,直到总共有6个Pod成功完成。
如果不指定completions和parallelism,默认值均为1。
k8s默认没有enable CronJob功能,需要在kube-apiserver
中加入这个功能,修改kube-apiserver
的配置文件/etc/kubernetes/manifests/kubeapiserver.yaml
,在启动参数中加上--runtime-config=batch/v2alpha1=true
,然后重启kubelet服务即可:systemctl restart kubelet.service
。
验证,输入命令kubectl api-versions
,或者执行更精确的命令:kubectl api-versions | grep batch/v2alpha1
健康检查
即Health Check。
k8s默认的健康检查机制:每个容器启动时都会执行一个进程,此进程由Dockerfile的CMD或ENTRYPOINT指定。如果进程退出时返回码非零,则认为容器发生故障,k8s就会根据restartPolicy重启容器。
Liveness探测指定k8s什么时候通过重启容器实现自愈;
Readiness探测指定k8s什么时候可以将容器加入到Service负载均衡池中,对外提供服务。
区别:
- Liveness探测和Readiness探测是两种Health Check机制,如果不特意配置,k8s将对两种探测采取相同的默认行为,即通过判断容器启动进程的返回值是否为零来判断探测是否成功
- 两种探测的配置方法完全一样,支持的配置参数也一样。不同之处在于探测失败后的行为:Liveness探测是重启容器;Readiness探测则是将容器设置为不可用,不接收Service转发的请求
- Liveness探测和Readiness探测是独立执行的,二者之间没有依赖,可单独使用,也可以同时使用。用Liveness探测判断容器是否需要重启以实现自愈;用Readiness探测判断容器是否已经准备好对外提供服务。
健康检查的应用场景:
- Scale Up
- Rolling Update
滚动更新通过参数maxSurge和maxUnavailable来控制副本替换的数量:
- maxSurge:控制滚动更新过程中副本总数超过DESIRED的上限。可以是具体的整数,也可以是百分百,向上取整。maxSurge默认值为25%
- maxUnavailable:控制滚动更新过程中,不可用的副本相占DESIRED的最大比例。可以是具体的整数,也可以是百分百,向下取整。maxUnavailable默认值为25%
maxSurge值越大,初始创建的新副本数量就越多;maxUnavailable值越大,初始销毁的旧副本数量就越多。
滚动更新失败,可以通过kubectl rollout undo回滚到上一个版本
回滚
kubectl apply
每次更新应用时,k8s都会记录下当前的配置,保存为一个revision,这样就可以回滚到某个特定revision。默认配置下,k8s只会保留最近的几个revision,可在Deployment配置文件中通过revisionHistoryLimit
属性配置revision数量。
数据管理
容器和Pod是短暂的。其含义是它们的生命周期可能很短,会被频繁地销毁和创建。容器销毁时,保存在容器内部文件系统中的数据都会被清除。为了持久化保存容器的数据,可以使用k8s Volume。Volume的生命周期独立于容器,Pod中的容器可能被销毁和重建,但Volume会被保留。
本质上,k8s Volume是一个目录,这一点与Docker Volume类似。k8s Volume也支持多种backend类型,包括emptyDir、hostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、Ceph等。
emptyDir Volume对于容器来说是持久的,对于Pod则不是。当Pod从节点删除时,Volume的内容也会被删除。但如果只是容器被销毁而Pod还在,则Volume不受影响。
emptyDir Volume的生命周期与Pod一致。Pod中的所有容器都可以共享Volume,它们可以指定各自的mount路径。
PVC
Pod通常是由应用的开发人员维护,Volume则通常是由存储系统的管理员维护。开发人员要获得上面的信息,要么询问管理员,要么自己就是管理员。这样就带来一个管理上的问题:应用开发人员和系统管理员的职责耦合在一起了。
解决方案:PVC
PV:PersistentVolume,是外部存储系统中的一块存储空间,由管理员创建和维护。与Volume一样,PV具有持久性,生命周期独立于Pod。
PVC:PersistentVolumeClaim ,是对PV的申请(Claim)。PVC通常由普通用户创建和维护。需要为Pod分配存储资源时,用户可以创建一个PVC,指明存储资源的容量大小和访问模式(比如只读)等信息,k8s会查找并提供满足条件的PV。
有了PVC,用户只需要告诉k8s需要什么样的存储资源,而不必关心真正的空间从哪里分配、如何访问等底层细节信息。这些Storage Provider的底层信息交给管理员来处理,只有管理员才应该关心创建PersistentVolume的细节信息。
accessModes:支持的访问模式有3种,ReadWriteOnce表示PV能以read-write模式mount到单个节点,ReadOnlyMany表示PV能以read-only模式mount到多个节点,ReadWriteMany表示PV能以read-write模式mount到多个节点。
persistentVolumeReclaimPolicy:指定当PV的回收策略为Recycle,支持的策略有3种,Retain表示需要管理员手工回收;Recycle表示清除PV中的数据,效果相当于执行rm -rf/thevolume/*
;Delete表示删除Storage Provider上的对应存储资源,例如AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume等。
回收PV
当不需要使用PV时,可用删除PVC回收PV。当PVC被删除后,k8s启动一个新Pod recycler-for-<pv>
,这个Pod的作用就是清除PV的数据。此时mypv1的状态为Released,表示已经解除了与PVC的Bound,正在清除数据,不过此时还不可用。当数据清除完毕,PV的状态重新变为Available,此时可以被新的PVC申请。
PV还支持Delete的回收策略,会删除PV在Storage Provider上对应的存储空间。NFS的PV不支持Delete,支持Delete的Provider有AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume。
PV动态供给
Static Provision:静态供给,提前创建PV,通过PVC申请PV并在Pod中使用。
Dynamical Provision:动态供给,即如果没有满足PVC条件的PV,会动态创建PV。相比静态供给,动态供给有明显的优势:不需要提前创建PV,减少管理员的工作量,效率高。动态供给是通过StorageClass实现的,StorageClass定义如何创建PV。StorageClass支持Delete和Retain两种reclaimPolicy,默认是Delete。
Secret & Configmap
Secret会以密文的方式存储数据,会以Volume的形式被mount到Pod,容器可通过文件的方式使用Secret中的敏感数据;此外,容器也可以环境变量的方式使用这些数据。
创建Secret的四种方法:
-
--from-literal
:一个--from-literal
对应一个信息条目 -
--from-file
:一个文件内容对应一个信息条目 -
--from-env-file
:文件中每行Key=Value对应一个信息条目 - YAML:文件中的敏感数据必须是通过base64编码后数据
查看Secret
kubectl get secret <secret_name>
kubectl describe secret <secret_name>
kubectl edit secret <secret_name> # 查看加密信息
与Secret一样,ConfigMap也支持四种创建方式。
Helm
两个概念:chart和release
- chart是创建一个应用的信息集合,包括各种k8s对象的配置模板、参数定义、依赖关系、文档说明等。chart是应用部署的自包含逻辑单元。可以将chart想象成apt、yum中的软件安装包
- release是chart的运行实例,代表一个正在运行的应用。当chart被安装到k8s集群,就生成一个release。chart能够多次安装到同一个集群,每次安装都是一个release。
Helm是包管理工具,包就是指chart。Helm能够:
- 从零创建新chart
- 与存储chart的仓库交互,拉取、保存和更新chart
- 在k8s集群中安装和卸载release
- 更新、回滚和测试release
Helm包含两个组件:Helm客户端和Tiller服务器。
Helm客户端是终端用户使用的命令行工具,用户可以:
- 在本地开发chart
- 管理chart仓库
- 与Tiller服务器交互
- 在远程k8s集群上安装chart
- 查看release信息
- 升级或卸载已有的release
Tiller服务器运行在k8s集群中,它会处理Helm客户端的请求,与k8s API Server交互。Tiller服务器负责:
- 监听来自Helm客户端的请求
- 通过chart构建release
- 在k8s中安装chart,并跟踪release的状态
- 通过API Server升级或卸载已有的release
总结:Helm客户端负责管理chart,Tiller服务器负责管理release。
chart
Helm的应用打包格式,由一系列文件组成,这些文件描述k8s部署应用时所需要的资源。chart将这些文件放置在预定义的目录结构中,通常整个chart被打成tar包,标注上版本信息,便于Helm部署。
Helm采用Go语言的模板来编写chart。Go模板非常强大,支持变量、对象、函数、流控制等功能。
如果存在一些信息多个模板都会用到,则可在templates/_helpers.tpl
中将其定义为子模板,然后通过templates函数引用。
randAlphaNum
、b64enc
、quote
都是Go模板语言支持的函数,函数之间可以通过管道|
连接。
Helm有两种方式传递配置参数。
常用命令:
helm create mychart # 创建chart
helm lint mychart # 检测chart的语法,报告错误以及给出建议
helm install --dry-run mychart --debug # 模拟安装chart,并输出每个模板生成的YAML内容
helm search mychart
helm repo add myrepo http://
helm install myrepo/mychart
helm repo update
任何HTTP Server都可以用作chart仓库。
Helm支持四种安装方法:
- 安装仓库中的chart,如
helm install stable/nginx
- 通过tar包安装,如
helm install./nginx-1.2.3.tgz
- 通过chart本地目录安装,如
helm install./nginx
- 通过URL安装,如
helm install https://example.com/charts/nginx-1.2.3.tgz
网络
基于扁平地址空间的网络模型,集群中的每个Pod都有自己的IP地址,Pod之间不需要配置NAT就能直接通信。另外,同一个Pod中的容器共享Pod的IP,能够通过localhost通信。
CNI,Container Networking Interface规范。CNI是由CoreOS提出的容器网络规范,使用插件(Plugin)模型创建容器的网络栈。
目前已有多种k8s网络方案,如Flannel、Calico、Canal、Weave Net等。因为它们都实现CNI规范,用户无论选择哪种方案,得到的网络模型都一样,即每个Pod都有独立的IP,可以直接通信。区别在于不同方案的底层实现不同,有的采用基于VxLAN的Overlay实现,有的则是Underlay,性能上有区别。再有就是是否支持Network Policy。
Network Policy
k8s的一种资源,Network Policy通过Label选择Pod,并指定其他Pod或外界如何与这些Pod通信。
默认情况下,所有Pod是非隔离的,即任何来源的网络流量都能够访问Pod,没有任何限制。当为Pod定义Network Policy时,只有Policy允许的流量才能访问Pod。不是所有的k8s网络方案都支持Network Policy。比如Flannel就不支持,Calico是支持的。
Canal用Flannel实现k8s集群网络,同时用Calico实现Network Policy。
Dashboard
k8s默认没有部署Dashboard,安装命令:kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/charts/kubernetes-dashboard.yaml
Dashboard会在kube-system namespace中创建自己的Deployment和Service,
Service是ClusterIP类型,为方便使用,可通过kubectl --namespace=kube-system edit service kubernetes-dashboard
修改成NodePort类型。
Dashboard支持Kubeconfig和Token两种认证方式。可以通过配置文件dashboard-admin.yaml
为Dashboard默认用户赋予admin权限。
kubectl apply -f dashboard-admin.yaml
命令使文件修改生效。
集群监控
Weave Scope
安装:``
Scope会自动构建应用和集群的逻辑拓扑,单击顶部PODS,会显示所有Pod以及Pod之间的依赖关系。
Scope支持关键字搜索和定位资源,还可以进行条件搜索,比如查找和定位MEMORY大于100MB的Pod。
Heapster
Heapster是k8s原生的集群监控方案。Heapster以Pod的形式运行,它会自动发现集群节点,从节点上的Kubelet获取监控数据。Kubelet则是从节点上的cAdvisor收集数据。Heapster将数据按照Pod进行分组,将它们存储到预先配置的backend并进行可视化展示。Heapster当前支持的backend有InfluxDB(通过Grafana展示)、Google Cloud Monitoring等。
整体架构
Prometheus Operator
Prometheus Operator基于基于Prometheus,可以监控k8s的API Server、Scheduler、Controller Manager等管理组件是否正常工作以及负荷是否过大。
Prometheus Operator的目标是尽可能简化在k8s中部署和维护Prometheus的工作。为方便管理,创建一个单独的Namespace monitoring,Prometheus Operator相关的组件都会部署到这个Namespace。文章来源:https://www.toymoban.com/news/detail-627053.html
架构
组件文章来源地址https://www.toymoban.com/news/detail-627053.html
- Prometheus Operator:在k8s中以Deployment运行。其职责是部署和管理Prometheus Server,根据ServiceMonitor动态更新Prometheus Server的监控对象。
- Prometheus Server会作为k8s应用部署到集群中。为了更好地在k8s中管理Prometheus,CoreOS的开发人员专门定义了一个命名为Prometheus类型的k8s定制化资源。我们可以把Prometheus看作一种特殊的Deployment,它的用途就是专门部署Prometheus Server
- Service就是Cluster中的Service资源,也是Prometheus要监控的对象,在Prometheus中叫作Target。每个监控对象都有一个对应的Service。比如要监控k8s Scheduler,就得有一个与Scheduler对应的Service。当然,k8s集群默认是没有这个Service的,Prometheus Operator会负责创建。
- Operator能够动态更新Prometheus的Target列表,ServiceMonitor就是Target的抽象。比如想监控k8s Scheduler,用户可以创建一个与Scheduler Service相映射的ServiceMonitor对象。Operator则会发现这个新的ServiceMonitor,并将Scheduler的Target添加到Prometheus的监控列表中。ServiceMonitor也是Prometheus Operator专门开发的一种k8s定制化资源类型。
- 除了Prometheus和ServiceMonitor,Alertmanager是Operator开发的第三种k8s定制化资源。我们可以把Alertmanager看作一种特殊的Deployment,它的用途就是专门部署Alertmanager组件。
集群日志管理
到了这里,关于《每天5分钟玩转kubernetes》读书笔记的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!