189 8069 5689
在日常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 为命名空间名称