Day74
service服务管理
服务基础
会变化的资源
会变化的Pod资源,当发现某一个pod不能使用的时候RS会在其它机器上再创建一个相同的Pod,以及对应的容器
service服务
会变化的pod给我们访问带来很多不便
sevice就是解决办法之一
service会创建一个cluster ip,这个地址对应资源地址,不管pod如何变化,service总能找到对应的pod,且cluster ip保持不变,如果pod对应着多个容器,service会自动在多个容器实现负载均衡
service通过port,nodePort,targetPort将访问请求最终映射到Pod的容器内部服务上
service的三种端口
targetPort: 是pod上容器服务监听端口,例如apache服务的端口是80
port:service暴露在cluster ip上的端口,是提供给集群内部客户访问service的入口,供集群内部服务访问使用
nodePort:是提供给集群外部客户访问service入口的一种方式,是集群外访问集群内资源的一种方式
使用命令行也可以定义服务
kubectl expose 资源类型 资源名称 --port=服务端口 --target-port=容器端口 --name-service的名字
服务自动发现
cluster-ip是集群分配的服务ip,供集群访问,在集群内部也可以通过服务的名称访问,服务的名称是通过coredns解析的,每个服务在创建的过程中都会自动完成注册
服务名称:<服务名称>.<名称空间>.svc.cluster.local
查询服务可以使用
kubectl get service
访问服务:集群内可以直接访问服务,但集群外无法访问服务
服务的代理模式
代理模式的种类
K8s v1.0服务支持userspace 代理模式
k8s v1.1 服务支持 iptable 代理模式
k8是 v1.8 服务支持ipvs 代理模式
在k8s v1.2 中kube-proxy的iptable模式成为默认设置,现在默认使用ipvs,如果不能满足要求回退至iptables模式
服务类型
service允许指定一个Type类型,默认是Cluster IP
cluster IP:通过集群的内部IP暴露服务,服务只能在集群内部访问,这样是默认的ServiceType
NodePort:通过每个Node上的IP和静态端口暴露服务。NodePort服务会路由到Cluster IP服务
LoadBalancer:使用云提供商的负载均衡器可以路由到iNodePort服务和Cluster IP 服务。
ExternalName:容器可以使用自定义的域名访问外网
Headless服务
有时不需要或者不想要负载均衡,以及单独的service IP。遇到这种情况,我们就可以创建Headless服务
Headless服务会把ip通过多个A记录的形式解析到具体的容器IP上面,多用于有状态的服务。
发布服务
外部服务
对外发布服务
有时我们需要集群内部和集群外部的服务能够实现互访
LoadBalancer:使用外部的云服务(需要支持,externallPs)
nodePort: 基于端口对外提供服务
lngress:使用ingress控制器
nodePort发布服务
详见后面的案例
访问nodePort
简单的nodePort也可以命令直接创建
kuberctl expose 资源类型 资源名称 --type-=Node --port=80 --target-port=80 --name=服务名称
nodePort开放的端口所有node均能访问
Ingress介绍
Ingress是什么
ingress公开了从集群外部到集群内service路由
可以将ingress配置为提供服务外部可访问的URL、负载均衡流量
ingress控制器通常由负载均衡器来实现
必须具有ingress控制器才能满足ingress的要求,仅创建资源无效。
ingress安装配置
ingress控制器安装
详见后面的案例
存储卷管理
ConfigMap
概述
configMap是在pod中映射的一种方式,允许你将配置文件与镜像文件分离,使得容器化的应用程序具有可移植性
为什么要使用ConfigMap
在日常生活中经常要修改各种配置文件的参数,数据库的地址用户名密码等,这些操作在容器内非常麻烦、POD在重启或者迁移的时候又会恢复到初始状态,使用ConfigMap就可以解决这样的问题。
持久化部署
为什么需要持久化存储卷
磁盘上的文件生命周期是短暂的,这就使得在容器中运行重要应用的时候就会出现一些问题。首先,当容器崩溃时kubectl会重启它,但是容器中的文件将丢失——容器以干净的状态重新启动。其次在Pod中同时运行多个容器时,这些容器之间通常需要共享文件。kubernetes中的Volume抽象就很好的解决了这些问题。
emptyDir
emptyDir是最基础的Volume类型,用于存储临时数据的简单空目录。如果Pod设置了emptyDir类型Volume,Pod被分配到Bode上的时候,会创建emptyDir,只要Pod运行在Node上,emptyDir都会存在(容器挂掉不会导致emptyDir丢失数据),