k8s-pod

由于不能将多个进程聚集在一个单独的容器中， 我们需要另 一种更高级的结构来将容器绑定在一起，并将它们作为一个单元进行管理，这就是 pod 背后的根本原理。

在包含容器的 pod 下，我们可以同时运行一些密切相关的进程，并为它们提供（几乎） 相同的环境， 此时这些进程就好像全部运行于单个容器中一样， 同时又保待着
一定的隔离。 这样一来， 我们便能全面地利用容器所提供的特性， 同时对这些进程来说它们就像运行在一起一样， 实现两全其美。

同一 pod 中容器之间的部分隔离

我们已经了解到容器之间彼此是完全隔离的， 但此时我们期望的是隔离容器组， 而不是单个容器， 并让每个容器组内的容器共享一些资源， 而不是全部（换句话说， 没有完全隔离）。 Kubemetes 通过配置 Docker 来让一个 pod 内的所有容器共享相同的 Linux 命名空间， 而不是每个容器都有自己的一组命名空间。
由千一个 pod 中的所有容器都在相同的 network 和 UTS 命名空间下运行（在这里我们讨论的是 Linux 命名空间）， 所以它们都共享相同的主机名和网络接口。 同样
地， 这些容器也都在相同的 IPC 命名空间下运行， 因此能够通过 IPC 进行通信。 在最新的 Kubernetes 和 Docker 版本中， 它们也能够共享相同的 PID 命名空间， 但是
该特征默认是未激活的。注意 当同一个 pod 中的容器使用单独的 PID 命名空间时， 在容器中执行 ps aux 就只会看到容器自己的进程。
但当涉及文件系统时， 情况就有所不同。 由于大多数容器的文件系统来自容器镜像， 因此默认情况下， 每个容器的文件系统与其他容器完全隔离。 但我们可以使
用名为 Volume 的 Kubernetes 资源来共享文件目录

容器如何共享相同的IP和端口空间

这里需强调的一 点是， 由于一个 pod 中的容器运行于相同的 Network 命名空间中， 因此它们共享相同的 IP 地址和端口空间。 这意味着在同一 pod 中的容器运行的
多个进程需要注意不能绑定到相同的端口号， 否则会导致端口冲突， 但这只涉及同-pod 中的容器。 由千每个 pod 都有独立的端口空间， 对于不同 pod 中的容器来说
则永远不会遇到端口冲突。 此外， 一个 pod 中的所有容器也都具有相同的 loopback网络接口， 因此容器可以通过 localhost 与同一 pod 中的其他容器进行通信。

三种探测容器的机制

2、TCP套接字探针尝试与容器指定端口建立TCP连接。如果连接成功建立，则探测成功。否则，容器重新启动。

3、Exec探针在容器内执行任意命令，并检查命令的退出状态码。如果状态码是 0, 则探测成功。所有其他状态码都被认为失败。

存活探针的附加属性

除了明确指定的存活探针选项，还可以看到其他属性，例如delay(延迟）、超时timeout(超时）、period(周期）等。delay=0s部分显示在容器启动后立即开始探测。超时timeout仅设置为1秒，因此容器必须在1秒内进行响应， 不然这次探测记作失败。每10秒探测一次容器(period=lOs), 并在探测连续三次失败(# failure=3)后重启容器。定义探针时可以自定义这些附加参数。

配置示例（设置初始延迟，将initialDelaySeconds属性添加到存活探针的配置中）

livenessProbe: 
  httpGet: 
    path: /port： 8080initialDelaySeconds: 15　　　　　　　　　　#Kubernetes 会在第—次探测前等待15秒

View Code

kubectl get pod nginx-6f7b4bf5bf-fgnf2 -n kzf -o yaml

2、kubectl explain 使用

在准备yaml时，可以转到http: /kubemetes.io docs/api上的 Kubemetes参考文档查看每个 API 对象支持哪些属性，也可以使用 kubectl explain
kubectl explain pods
Kubectl 打印出对象的解释并列出对象可以包含的属性，接下来就可以深入了解各个属性的更多信息,例如，可以这样查看 spec 属性
$ kubectl explain pod.spec

View Code

3、查看pod 的IP

kubectl get po -o wide -n kzf

View Code

Pod 删除

Tips:

在删除 pod 的过程中，实际上我 在指示 Kub es 终止该 pod 中的所有容器Kub etes 向进程发送 SI GTE阳信号并等待 定的秒数（默认为 30），使其正常关闭 如果它没有及时关闭，则通过 SIGKILL 终止该进程 因此，为了确保你
的进程总是正常关闭，进程需要正确处理 SIGTERM 信号
提示:还可以通过指定多个空格分隔的名称来删除多个 pod （例如 kubectldelete po podl pod2)

按照名称删除Pod

kubectl delete pod kubadf

使用标签选择器删除Pod

kubectl delete pod -1 method=asdfa

通过命名空间删除pod

kubectl delete pod-name -n namspace-name　　　　#删除指定命名空间下的pod
kubectl delete ns namespace-name　　　　　　　　 #通过删除整个命名空间来删除 pod
kubectl delete pods --all -n kzf　　　　　　　　#删除命名空间下所有Pod ,不删除命名空间
kubectl delete all --all -n kzf　　　　　　　　#删除当前命名空间中的所有资源，可以删Replicationcontrol和pod, 以及所有 service。

注意使用 all 关键字删除所有内容并不是真的完全删除所有内容。 一些资源比如 Secret会被保留下来， 并且需要被明确指定删除。

Notice: 如果pod 是通过ReplicationCcontroller创建的，那么只删除pod 还会自动产生新Pod ,此情况需要同时删除这个rc

日志

容器化的应用程序通常会将日志记录到标准输出和标准错误流， 而不是将其写入文件， 这就允许用户可以通过简单、 标准的方式查看不同应用程序的日志。

日志查看

docker  logs  <container id>#前提是 ssh命令登录到pod正在运行的节点， 并使用docker logs命令查看其日志
kubectl logs pod-name　　　　　　　　　　#无需登录容器所在节点，只在master 或其他可以调用k8s api 的客户端即可查看，此命令实际查看的仍然是容器日志
kubectl logs pod-name  -c container-name　 # pod 中存在多个容器时，查看日志要指定要查看日志的容器名称

View Code

Notice

1、每天或者每次日志文件达到10MB大小时， 容器日志都会自动轮替。kubectl logs命令仅显示最后一次轮替后的日志条目。

2、当一个pod被删除时，它的日志也会被删除。 如果希望在pod删除之后仍然可以获取其日志， 我们需要设置中心化的、 集群范围的日志系统， 将所有日志存储到中心存储中。

3、默认查看的是当前Pod 的日志，如果pod 重启了，那么想要查看上一个pod 日志，可以通过命令 kubectl logs mypod --previous 查看

Pod端口转发

两种方式

1、kubectl expose 命令创建了 一个service, 以便在外部通过service 访问 pod。

2、kubectl port-forward 命令完成 　　　　　　　　　　　　　　　　　　　　　　#一般用于测试，生产环境都是通过service转发端口
   kubectl  port-forward  kubia-manual  8888:8080

View Code

标签

一、介绍

标签是一种简单却功能强大的Kubemetes特性， 不仅可以组织pod, 也可以组织所有其他的Kubemetes资源。 详细来讲， 标签是可以附加到资源的任意键值对，

用以选择具有该确切标签的资源（这是通过标答选择器完成的 ）。 只要标签的key在资源内是唯一的，一个资源便可以拥有多个标签。 通常在我们创建资源时就会将标

签附加到资源上， 但之后我们也可以再添加其他标签， 或者修改现有标签的值， 而无须重新创建资源。

Tips： 关于标签有单独一篇博文介绍