MyLinuxOPS

在Docker中，文件系统与Docker容器具有相同的生命周期。在多节点运行Docker的环境中，应用会因为各种原因而退出。于是在多节点中运行的容器就面临着一种境况，如某个容器崩溃、节点崩溃、用户误删除而导致容器被删除。若我们直接将数据存在容器内的文件系统上数据也将丢失，为了避免数据与容器产生直接绑定关系，我们应该将其数据存储在容器文件系统之外，而存储方式则是为容器引入外部的存储空间。 外部存储分类外部的存储空间分为两类： Host：宿主机级别，在节点本地进行存储。 Network Storage：网络存储 对于Host类型的存储来说，若在其节点上运行的容器崩溃了，再次启动容器时，只能在同一个节点上进行复，而对于集群环境的k8s来说这种类型的存储不适用。因此使用网络存储更加合适。 共享式存储设备共享式存储设备分为： 多路并行读写 多路只读 单路读写 pod使用Volume步骤 在Pod上定义存储卷，并关联到目标存储服务上 在需要用到存储卷的容器上挂载其所属的Pod的存储卷 pod中使用volume的资源清单格式12345678910111213spec: volumes: ...

服务本身是为一组pod提供一个固定的入口，因此我们要能到达这些pod对象都要经由service ClusterIP来实现，因此配置在Service上的ClusterIP就称之为Service的头(Head)，而无头服务即指没有ClusterIP的服务。 在互联网中DNS本身就具有负载均衡功能，这种无头服务是依靠DNS自身的负载均衡功能来实现的。 Service的功能是提供一个访问入口并将请求调度给后端的Pod，现在前端有CoreDNS，那我们就能将Service ClusterIP进行省略，让用户访问时使用主机名或服务名来访问，而服务名解析的结果就不到ClusterIP，而是直接到达Pod IP，像这种服务称之为无头服务。 Headless Service作用应用分为两类，stateful和stateless。 stateful：每一个个体都具有一定的独特性，由其存储的状态决定。 stateless：每一个个体没有特定的意义，随时可以替代。 headless service在做名称解析时，每一个个体都有其Pod名称或Pod的唯一标识作为其名称来进行识别，于是这种DNS的解析记录就变 ...

ExternalName是Service的第四种类型，其主要的作用是将集群外部服务的服务引入到集群内部来，能实现类似于常规服务一样的名称解析，服务发现等功能，但是它所有的对应的服务记录维护既不需要标签选择器关联任何对象，也无需定义任何端口和端点，但是必须在服务定义中使用ExternalName定义一个cname用于返回真正提供服务的名称的别名。 ExternalName类型Servcie在coreDNS中解析为一个cname，其对应的是一个外部服务的名称，该服务要能在外部DNS中被解析；此处的外部指的是公网DNS，或者在CoreDNS中通过forward转发给公司内部的DNS。 ExternalName示例1.编写配置清单 12345678910111213141516root@k8s-master01:~/yaml/chapter07# vim externalname-redis-svc.yamlkind: ServiceapiVersion: v1metadata: name: externalname-redis-svc namespace: defaultspec: t ...

即便Service有了IP，但是若集群上有1000+Service，使用IP地址去访问是不可能的事情，所以我们需要以Service的名称来访问服务。 由于k8s上的服务是动态管理的，随时有可能创建删除。如果使用传统的DNS解析那么每一次创建一个服务就得去手动管理其解析记录。 服务发现在it领域有很多种解决方法，如Zookeeper，Euraka，Consul等。如果使用这些方法的话服务注册和发现能很好解决，但名称解析依然无法联动，因而k8s没有使用这总服务发现机制，而是将传统的DNS服务直接提供了一个云原生解决方案，它支持从APIServer上动态加载相关的Service信息及端点信息，并自动生成资源记录。 这种DNS就成了k8s上服务注册和服务发现的动态总线：kubeDNS。 其实现方案上有3代： 第一代：SkyDNS 第二代：KubeDNS 第三代：CoreDNS K8S的服务发现在K8S中服务发现有两种方法，基于环境变量或基于DNS服务。 基于环境变量的服务发现在k8s中基于环境变量的方法又有两种： （1）Kubernetes Service环境变量Kubernetes为每个 ...

创建一个Service资源后，他会自动创建出一个同名的Endpoint资源。因为Service并不直接匹配其后端的标签，而是交由Endpoint进行匹配，而匹配过程是由Endpoint控制器完成的。 123456789101112131415161718192021# 查看系统上存在的SVCroot@k8s-master01:~# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEdemoapp NodePort 10.111.8.128 <none> 80:31156/TCP 7ddemoapp-externalip-svc ClusterIP 10.96.141.139 172.16.11.75 80/TCP 12hdemoapp-loadbalancer-svc LoadBalancer ...

ipvs代理模式下的ClusterIP在iptables代理模式下，每一个Service会生成很多的iptables规则，在Service较多的情况下，itpables规则会更多，在性能上将会由很大的影响。而ipvs的代理模式则比iptables相对简单的多。 ipvs代理模式下，kube-proxy会在每个节点上创建一个名为kube-ipvs0的虚拟接口，并将集群所有Service对象的ClusterIP和ExternalIP都配置在该接口； kube-proxy为每个service生成一个虚拟服务器（Virtual Server）的定义。 ipvs类型：默认使用nat类型；仅需要借助于极少量的iptables规则完成源地址及端口转换等功能。 iptables代理模式改ipvs云原生应用支持直接修改环境变量或修改配置文件中非关键配置后动态加载，我们修改配置后会通过配置中心加载信息后自动重载，用户对此无所感知。我们只需要提供配置中心，将需要修改的配置在配置中心上进行替换，经过一段时间后就自动生效了。 k8s上提供了一个非常重要的资源ConfigMap来模拟为所有pod中的应用提供配置中 ...

在k8s中Service是一个标准的资源类型，为动态的一组pod提供一个固定的访问入口，使用一个ClusterIP来标识的。ClusterIP存在于Cluser Network中。 Service的工作原理1.Service如何识别其背后有多少Pod? 在每一个对应的Pod之上添加一个独特的标签，前端对应的Service将使用标签选择器来挑选中一组pod。任何能被Service的标签选择器所选中的目标都将作为该Service的后端端点。 Service不但能把标签选择器选中的Pod识别为自己的后端端点，他还能对后端端点做就绪状态检测，如果后端端点就绪，那就么他就会将其加入到自己的后端可用端点列表中去，否则将移除。而此功能并非由Service自己实现的，而是借助了一个中间组件endpoint来实现的。 endpint也是一个标准的资源类型。只不过Service会自动去管理Endpoint资源 1234root@k8s-master01:~/yaml/chapter04# kubectl get endpointsNAME ENDPOINTS ...

自定义Endpoint资源可以将集群外部的服务如mysql、zookeeper，引入到集群内来。这种集群外的服务除非使用service的externalName，否则用Service来引入是不合适的，因为他不会自动创建出endpoint，也没有标签来选择集群外部的服务。 我们可以直接在集群上创建一个endpoint资源，为endpoint资源指定端点为集群外部的资源，前提是endpoint资源能和集群外部资源通信。在endpoint之上人为的创建一个Service资源。当客户端访问Service时就相当于访问到集群外部的服务。 手动创建的endpoint存在缺点，缺点在于手动创建的endpoint无法进行就绪状态检测。如果需要将某个端点定义为未就绪状态，则需要手动修改配置清单并重新应用。 Endpoint资源使用格式123456789101112131415161718192021222324apiVersion: v1kind: Endpointmetadata: # 对象元数据 name: namespace:subsets: # 端点对象的列表- addresse ...

iptables代理模式下的ClusterIPiptables代理模式下的ClusterIP，每个Service在每个节点上（由kube-proxy负责生成）都会生成相应的iptables规则： KUBE-SERVICES：包含所有ClusterIP类型的Service的流量匹配规则，由PREROUTING和OUTPUT两个内置链直接调用；每个Service对象包含两条规则定义，对于所有发往该Service（目标IP为Service_IP且目标端口为Service_Port）的请求报文，前一条用于为那些非源自Pod网络（! -s 10.244.0.0/16）中请求报文借助于KUBE-MARQ-MASK自定义链中的规则打上特有的防火墙标记，后一条负责将所有报文转至专用的以KUBE-SVC为名称前缀的自定义链，后缀是Service信息hash值。 代码块112345678910111213141516171819# 用户空间的所有pod或进程的出栈报文全都跳转给KUBE-SERVICES，如果目标地址是某个Services之一其必然会被KUBE-SERVICE中规则所匹配。root@k ...

以下是一个完整的pod清单示例，可以参考进行修改使用。 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364apiVersion: v1kind: Podmetadata: name: all-in-one namespace: defaultspec: initContainers: - name: iptables-init image: ikubernetes/admin-box:latest imagePullPolicy: IfNotPresent command: ['/bin/sh','-c'] args: ['iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80'] securityContext ...