容器化带来的问题
- 自动调度: 在Pod创建之前,用户无法预知Pod所在的节点和ip地址
- 一个已经存在的Pod在运行过程中,如果出现故障,Pod也会在新的节点使用新的ip进行部署
- 应用程序访问服务的时候,地址也不能经常变换
- 多个相同的pod如何访问他们上面的服务
服务原理
自动感知 服务会创建一个clusterIP这个地址对应资源地址,不管Pod如何变化,服务总能找到对象的Pod,且clusterIP保持不变
负载均衡: iptables/LVS
自动发现: 服务创建时会自动在内部DNS上注册域名
- 域名: <服务名称>.<名称空间>.svc.cluster.local
cluster IP 服务
cluster IP类型: 默认的servicetype ,通过集群内部ip暴露服务,选择该值时服务只能够在集群内部访问
spec:
type:Cluster IP
selector: (后端pod上打标签)
app: web (标签) 靠标签找pod
ports: 服务上监听的端口 targetPort(后端监听端口)
- portocol: 协议
port:80 原端口
targetPort :80 目标端口
dnf install -y bind-utils (解析域名)
host mysvc.default.svc.cluster.local 10.245.0.10
创建服务后端应用
clusterIP 工作原理
kube-proxy 是在所有节点上运行的代理,旁路模式,无需人工,自动感知
可以设置更新iptables/LVS 规则,在服务创建时,还提供服务地址DNS自动注册与服务发现功能
使用固定IP
clusterIP 是随机分配的,如果想使用固定IP,可以自定义,但是IP的范围必须符合CIDR
对外发布应用
发布服务
cluster IP服务可以解决集群内应用互访的问题,但外部的应用无法访问集群内的资源,某些应用需要访问集群内的资源,我们就需要对外发布服务
服务类型
clusterIP:默认类型,可以实现Pod的自动感知与负载均衡,核心服务类型,但是clusterIP不能对外发布。
NodePort 或 Ingress 可以实现对外发布
nodePort 四层 端口映射(30000-32767)
ingress 七层 (http协议)能够解析和管理插件
ingress 1,规则 2,控制器
规则负责制定策略,控制器负责执行
如果没有控制器,单独设置规则无效
控制器下载地址: https://github.com/kubernetes/ingress-nginx
igress 可以识别域名
ingress
- path:
pathType: Prefix (宽松模式,可以访问目录及子目录) 和 Exact(严格模式,只能访问指定路径)
backend:
service:
name: mysvc
port:
number: 80
curl -H "Host: nsd.tedu.cn" http://192.168.1.51
Dashboard 为web 管理工具
是基于网页的kubernetes用户界面
同时展示k8s集群中的资源状态信息和所有报错信息
ServiceAccount
用户认证
所有K8s集群都有两类用户,k8s 管理的服务帐号和普通用户。
普通用户是以证书或秘钥形式签发;主要用途是认证和鉴权,集群中并不包含用来代表普通用户帐号的对象,普通用户的信息无法调用和查询
服务帐号是k8s APi 所管理的用户,绑定到特定的名字空间,与一组secret凭据相关联,供Pod调用相应的授权
k8s 支持多种鉴权模块 Node,RBAC,ABAC,Webhook API
Node 默认
ABAC 属性鉴权
RBAC 角色鉴权 先有岗位后有人 组织中角色的权限
Webhook HTTP回调
RBAC声明了四种K8s对象:
Role: 用来在某个名称空间创建授权角色,创建role,必须指定所属的名字空间的名字
clusterRole : 可以和role相同完成授权。但属于集群范围,对所以名称空间有效
roleBinging: 将角色中定义的权限赋予一个或者一组用户,可以使用Role或clusterRole完成授权
clusterRoleBinging 在集群范围执行授权,对所有名称空间有效,只能使用clusterRole完成授权