十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
在日常kubernetes的运维中,经常遇到pod的网络问题,如pod间网络不通,或者端口不通,更复杂的,需要在容器里面抓包分析才能定位。而kubertnets的场景,pod使用的镜像一般都是尽量精简,很多都是基于alpine基础镜像制作的,因而pod内没有ping,telnet,nc,curl命令,更别说tcpdump这种复杂的工具了。除了在容器或者镜像内直接安装这些工具这种最原始的法子,我们探讨下其他法子。
创新互联于2013年创立,是专业互联网技术服务公司,拥有项目网站建设、成都网站建设网站策划,项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命,1280元新巴尔虎右做网站,已为上家服务,为新巴尔虎右各地企业和个人服务,联系电话:18982081108
项目地址 kubect debug ,
kubectl-debug 是一个简单的 kubectl 插件,能够帮助你便捷地进行 Kubernetes 上的 Pod 排障诊断。背后做的事情很简单: 在运行中的 Pod 上额外起一个新容器,并将新容器加入到目标容器的 pid , network , user 以及 ipc namespace 中,这时我们就可以在新容器中直接用 netstat , tcpdump 这些熟悉的工具来解决问题了, 而旧容器可以保持最小化,不需要预装任何额外的排障工具。操作流程可以参见官方项目地址文档。
一条 kubectl debug命令背后是这样的
步骤分别是:
接下来,客户端就可以开始通过 5,6 这两个连接开始 debug 操作。操作结束后,Debug Agent 清理 Debug 容器,插件清理 Debug Agent,一次 Debug 完成。
有2种进入pod 所在net ns的方式,前提都是需要登录到pod所在宿主机,且需要找出pod对应的容器ID或者名字。
nsenter为util-linux里面的一个工具,除了进入容器net ns,还支持其他很多操作,可以查看官方文档。
查看Oracle数据库监听是否启动应使用lsnrctl命令,命令如下
$ lsnrctl status
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ocm1.oracle.domain)(PORT=1521)))
STATUS of the LISTENER
————————
Alias LISTENER
Version TNSLSNR for Linux: Version 10.2.0.1.0 – Production
Start Date 17-MAY-2011 21:03:40
Uptime 0 days 0 hr. 2 min. 49 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/app/oracle/product/10.2.1/db/network/admin/listener.ora
Listener Log File /u01/app/oracle/product/10.2.1/db/network/log/listener.log
Listening Endpoints Summary…
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=ocm1.oracle.domain)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=ocm1.oracle.domain)(PORT=1522)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=ocm1.oracle.domain)(PORT=1600)))
Services Summary…
Service “POD” has 1 instance(s).
Instance “POD”, status READY, has 1 handler(s) for this service…
Service “POD1″ has 1 instance(s).
Instance “POD”, status UNKNOWN, has 1 handler(s) for this service…
Service “PODS” has 1 instance(s).
Instance “POD”, status READY, has 2 handler(s) for this service…
Service “pod_XPT” has 1 instance(s).
Instance “POD”, status READY, has 1 handler(s) for this service…
Service “repos” has 2 instance(s).
Instance “repos”, status UNKNOWN, has 1 handler(s) for this service…
Instance “repos”, status READY, has 1 handler(s) for this service…
Service “repos_XPT” has 1 instance(s).
Instance “repos”, status READY, has 1 handler(s) for this service…
The command completed successfully
lsnrctl命令常用参数:
$ lsnrctl status:检查当前监听器的状态
$ lsnrctl start [listener-name] 启动所有的监听器,可以指定名字来启动特定的监听器
$ lsnrctl stop [listener-name] 关闭所有的监听器,可以指定名字来关闭特定的监听器
$ lsnrctl reload 重启监听器,此命令可以代替lsnrctl stop,lsnrctl start
$ lsnrctl help 可以显示所有可用的监听器命令
首先我们要明确一个概念,Kubernetes并不是只支持Docker这一个容器运行时,通过我的另一篇文章什么是Kubernetes的CRI-容器运行时接口介绍的内容,我们知道Kubernetes通过CRI这个抽象层,支持除Docker之外的其他容器运行时,比如rkt甚至支持客户自定义容器运行时。
这个问题不易回答的原因,是因为包含了这一组业务容器的逻辑单元,没有一个统一的办法来代表整个容器组的状态,这就是Kubernetes引入pod的概念,并且每个pod里都有一个Kubernetes系统自带的pause容器的原因,通过引入pause这个与业务无关并且作用类似于Linux操作系统守护进程的Kubernetes系统标准容器,以pause容器的状态来代表整个容器组的状态。
Kubernetes里的每个pod都有唯一的IP地址。Pod的IP地址可以通过命令kubectl describe pod来查看:
这个IP地址用来支持Kubernetes的底层网络借助Flannel,openswitch等虚拟二层网络技术来实现集群内任意两个pod之间的TCP/IP通信。也就是说,一个Pod内的容器与另外主机的pod容器能够直接通信。
Pod被创建后,会被Kubernetes master调度到某个具体的node上进行绑定:
上图中蓝色高亮区域代表的就是这个被观察的pod被分配到的node的名称。
pod和node绑定之后,node上的kubelet进程会对pod进行初始化操作,启动相关的Docker容器。
上图红色区域显示了Docker容器从正在从远端pull镜像,到pull完成,到创建Docker容器运行实例,到最终启动实例的状态迁移过程。
一个pod是一组紧密相关的容器,是一起运行在同一个工作节点上,以及同一个Linux命名空间中。每个pod就像是一个独立的逻辑机器,拥有自己的IP、主机名、进程等,运行一个独立的应用程序。
pod是逻辑主机,一个pod的所有容器都运行在同一个逻辑机器上,其他pod中的容器,即使运行在同一个工作节点上,也会出现在不同的节点上。即一个pod包含多个容器时,这些容器总是运行在同一个工作节点上,一个pod绝不可能跨多个工作节点。
举例 :
每个pod自有IP,包含1个或多个容器,每个容器运行一个应用进程
查看pod命令
$ kubectl get pods
READY:0/1 表示pod的单个容器显示为未就绪的状态;相反,1/1表示已就绪;
STATUS: Pending 表示pod处于挂起状态;相反,Running表示pod处于运行状态;
运行应用两大步骤:1)构建镜像并推送至镜像仓库中;2)K8s创建pod进行调度;
流程:
1)本地构建镜像;
2)推送镜像至镜像仓库;
3)kubectl创建并部署应用;
4)kubectl发出REST请求至REST API服务器;
5)创建pod并调度到工作节点;
6)kubelet收到通知;
7)kubelet告知Docker运行镜像;
8)Docker从镜像仓库中拉取镜像;
9)Docker创建并运行容器;
如果单个容器中运行多个不相关的进程,保持所有进程运行、管理它们的日志将很难,需要包含一种在进程崩溃时能够自动重启的机制,同事,这些进程都将记录到相同的标准输出中,很难确定每个进程分别记录的内容。
不能讲多个进程聚集在一个单独的容器中,需要pod将容器绑定在一起,并将它们作为一个单元进行管理,在包含容器的pod下,可以同时运行一些密切现骨干的进程,并为其提供相同的环境,此时这些进程就好像全部运行于单独的容器中,同时保持一定的隔离性。
k8s可以通过配置docker让一个pod内的所有容器共享相同的Linux命名空间(network、UTS命名空间、IPC命名空间),从而使容器都共享相同的主机名、网络名和IPC通信。
同一个pod中的容器运行的多个进程不能绑定到相同的端口号,否则会端口冲突(每个pod都有独立的端口空间,不同pod中的容器不会有端口冲突现象。)
同一个pod中的容器具有相同的loopback网络接口,所以容器可以通过localhost与同一个pod中的其他容器进行通信。
注意 :
容器不应该包含多个进程,pod也不应该包含多个并不需要运行在同一主机上的容器。如下图:
1)yaml中使用的kubernetes API版本和yaml描述的资源类型;
2)metadata:包括名称、命名空间、标签和关于该容器的其他信息;
3)spec:包含pod内容的实际说明,如pod的容器、卷和其他数据;
4)status:包含运行中的pod的当前信息,如pod所处的条件、每个容器的描述和状态,以及内部IP和其他基本信息。
描述信息:
1)该文件遵循Kubernetes API的v1版本;
2)描述的资源类型是pod;
3)资源名称为kubia-manual;
4)该pod由基于luksa/kubia镜像的单个容器组成;
5)容器名称为kubia;
6)容器监听的端口是8080;
按名称删除
$ kubectl delete po pod_name
其中, pod_name 为pod名称;删除命令指示uk8s终止该pod中所有容器,k8s向进程发送一个SIGTERM信号并等待一定的秒数(默认30s),使得其正常关闭,若未及时关闭,则通过SIGKILL终止进程。
删除多个pod
$ kubectl delete po pod_name1 pod_name2
多个pod删除使用空格隔开;
按照标签删除
$ kubectl depete po -l tag_key=tag_value
其中, tag_key 为标签健, tag_value 为标签值;
按照整个命名空间删除
$ kubectl delete ns namespace_name
其中, namespace_name 为命名空间名称