pod属于基础架构容器,拥有网络协议栈,ip端口
看上面的容器有时候地址是看不到的
基础架构容器就显示command为pod
另外的节点上的pod也一样
k8s不做dnat暴露,直接基于地址访问即可,需要做dnat,除了proxy级别的时候
deployment示例:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
Unique key of the Deployment instance
name: deployment-example
spec:
2 Pods should exist at all times.
replicas: 2
template:
metadata:
labels:
# Apply this label to pods and default
# the Deployment label selector to this value
app: nginx
spec:
containers:
- name: nginx
# Run this image
image: nginx:1.12(docker.io/mageedu/bbox.httpd)
做一个service实例,可以放在之前的文件里也可以放在另外 文件里
-s指明访问接口,master的8080,create创建 -f指明配置文件
get查看服务
查看iptables规则
pod能访问,因为serivce在pod节点上,master访问不了
kill掉以后,可能自己会起来,只不过ID会不同
访问不了可能路由有问题,把一个podkill掉
会自动起来
调度到本机上就正常,调度到其他主机上就不正常
跨主机的路由地址可能有些问题
从另外的pod访问另外的主机
需要找一个合适的客户端去访问
对k8s集群,即便每个节点上的容器,彼此间互相访问,没有任何问题,因为得到的地址是可路由地址,但是在集群外访问是不可以的
如果node节点本身有公网地址,把对应的容器端口暴露出来了(刚才的3320),如果有公网IP用公网ip访问这个端口是没有什么问题的,私有ip访问不到,是属于集群的,而且是分配的特殊网段
service地址也是集群私有的
**使用docker新版的另一资源ingress
**https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#configmap-v1-core
ingress相当于 把master节点主机物理地址比如172.16,0.69 把这个地址的8080端口某个url.映射成内部的某个服务地址,haproxy可以实现所谓的反代功能,反代时也能基于所谓的4层协议来进行
可以理解非标准服务的端口,基于4层协议,用的非http协议的端口。通过4层也能照样向外进行输出
因此如果给master节点一个公网地址,让客户端直接访问公网地址,让这个公网地址,基于所谓的反代方式,url反代方式,反代至两个服务上,给每个服务定义一个专用的url
/bbox
如果用户请求了master公网地址,或者是一个公网地址,解析了很多主机名
比如访问/bbox.magedu.com/跟的时候,把这个跟和service的/bbox映射起来,访问跟的时候,就相当于访问内部私网地址的service ip之上的bbox,这就是内外的url映射
跟之前nginx类似,两个web服务器,需要反代的时候,前面放nginx即可,nginx反代的时候,前后的url可以不一样
跟这边的道理一样
bbox对应的其实就是service
ingress的意思就是把内部的某个service,定义出在集群上专用的url,把url和它之间建立起映射关系,
也可以公网地址只有一个,让内网地址内外都是要url来进行映射
1.1.1.1、Bbox访问的是内网的bbox,对应的就是service
k8s在企业真正使用的时候,也不是把所有都容器化的,不必要使用ingress
对k8s来讲,整个地址是纯粹只能在集群内使用,即便定义成service了,service地址也只是仅限内部使用的是有地址,因此在集群外部或内部,要访问应用的时候是做不到的,除非定义ingress让内外建立映射关系
可以想象成把master的某个url映射成某个service上去,master地址可以对外通信
所以master是一个总的调度器入口
基于url映射的方式,主机名跟的映射,而不是专门的url映射
https://github.com/JohnMorales/kubernetes-dashboard
实现了用api 访问不再使用yaml格式的文件,而是可以使用图形界面,来尝试启动pod,定义service
https://github.com/kubernetes-retired/kube-ui这个更好
站点是google托管的镜像,需要vpn
**保存过去10个历史副本 revisionHistorylimit
**
镜像文件在gcr,.io google containers 是访问不到的
有人把这个镜像文件拖下来,导入到dockerhub了,kubernetest-dashboard
作为自己部署应用时候的所使用的镜像文件
https://hub.docker.com/r/ist0ne/kubernetes-dashboard-amd64
apiserver,也要修改,否则有可能会失败
手动把这个镜像拖下来
node1,node2都操作
没有运行可以直接创建,创建以后调度到node2上
只运行了一个pod
表示启动 镜像文件仍然是失败的
之前改的地方有问题
master是主机名在容器内解析不了这个主机,容器有自己的hosts文件,跟节点没有关系,应该改成地址
把刚才的部署delete,重新create
调度到node1了,就去看node1的
访问对应的9090就可以进行访问了
cluster-info查看集群的状态信息
基于物理地方访问,就可以在外部进行访问,自动映射到内部去
可以创建deployment
dashboard可以理解为kubernetes的附件addon
两个要点,
1.镜像文件要直接从能直接访问的registry来获取
2.指明apiserver地址,因为没有部署dns服务,不能自己发现master在哪里,不能使用主机名
还可以部署监控系统
每个节点来讲,4194端口可以被直接访问,cAdvisor是内建的只能监控一个资源,
集成起来统一看就使用heapster
各种状态是每一个节点独立的
每一个节点自己有一个cAdvisor,想看节点上有什么资源,用cAdvisor即可,4194端口,k8s集群node有很多,不可能一个个看
可以找一个节点,通过每一个主机的cAdvisor,把这些信息搜集到一起,需要存起来,时间序列存储,通常用influxDB,收集想看,heapster收集器手机各节点的信息存储到influxDB中
想要看还需要一个专门的查看器,grafana
每个主机上有一个监控的插件,展示接口是cAdvisor
heapster用于连接各cadvisor收集器,把数据收集起来放起来,统一放在influxDB
gcr你是访问不到的https://github.com/kubernetes-retired/heapster
用influxdb进行部署的有三个文件
修改镜像文件地址
把镜像拖下来
还有heapster
两个节点都需要pull,因为不确定会部署到哪个节点上
source 指明kubernetes的集群的地址和influxdb的地址,这里都是基于kubedns名字解析来访问的,有可能会出错,因为没有服务发现,服务注册的功能,
先测试一下
node2上就运行了pod,容器
查看日志,influxdb已经启动起来了
查看pod地址没有服务注册和服务发现的功能
修改sink
两个节点都拖下来
创建heapsterpod
在node1节点上,已经启起来了
从各个节点的cadvisor获得数据往这里存了
还需要展示
两个节点都pull一下拖一下导入到registry
先试一下
cluster info可以看到运行的信息
influxdb默认监听8086端口
数据源要指定influxdb格式
数据源就添加好了
使用k8s的时候,就是定义一个k8s的文件,里面deployment,service