网站访客抓取,国内网站搭建,沈阳高端网站开发建设,网站开发学什么比较有优势笔记
概念
Pod是脆弱的#xff0c;但应用是健壮的。
kubelet运行在Cluster所有节点上#xff0c;负责启动Pod和容器。kubeadm用于初始化Cluster。kubectl是k8s命令行工具。通过kubectl可以部署和管理应用#xff0c;查看各种资源#xff0c;创建、删除和更新各种组件。 …笔记
概念
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 disktypessd 查看节点的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的IPk8s则负责建立和维护Service与Pod的映射关系。无论后端Pod如何变化对客户端没有任何影响因为Service没有变。
Cluster IP是一个虚拟IP是由k8s节点上的iptables规则管理的。可以通过iptables-save命令打印出当前节点的iptables规则。Cluster的每一个节点都配置了相同的iptables规则这样就确保了整个Cluster都能够通过Service的Cluster IP访问Service。
除可以通过Cluster IP访问Servicek8s还提供更为方便的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
ClusterIPService通过Cluster内部的IP对外提供服务只有Cluster内的节点和Pod可访问这是默认的Service类型NodePortService通过Cluster节点的静态端口对外提供服务。Cluster外部可以通过NodeIP:NodePort访问ServiceLoadBalancerService利用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: 6parallelism: 2配置解读每次运行两个Pod直到总共有6个Pod成功完成。 如果不指定completions和parallelism默认值均为1。
k8s默认没有enable CronJob功能需要在kube-apiserver中加入这个功能修改kube-apiserver的配置文件/etc/kubernetes/manifests/kubeapiserver.yaml在启动参数中加上--runtime-configbatch/v2alpha1true然后重启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 UpRolling 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 PVPersistentVolume是外部存储系统中的一块存储空间由管理员创建和维护。与Volume一样PV具有持久性生命周期独立于Pod。
PVCPersistentVolumeClaim 是对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文件中每行KeyValue对应一个信息条目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客户端负责管理chartTiller服务器负责管理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通信。
CNIContainer 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 --namespacekube-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 monitoringPrometheus Operator相关的组件都会部署到这个Namespace。
架构 组件
Prometheus Operator在k8s中以Deployment运行。其职责是部署和管理Prometheus Server根据ServiceMonitor动态更新Prometheus Server的监控对象。Prometheus Server会作为k8s应用部署到集群中。为了更好地在k8s中管理PrometheusCoreOS的开发人员专门定义了一个命名为Prometheus类型的k8s定制化资源。我们可以把Prometheus看作一种特殊的Deployment它的用途就是专门部署Prometheus ServerService就是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和ServiceMonitorAlertmanager是Operator开发的第三种k8s定制化资源。我们可以把Alertmanager看作一种特殊的Deployment它的用途就是专门部署Alertmanager组件。
集群日志管理
