pod

apiVersion: v1 kind: Pod metadata: name: liveness-httpget namespace: default spec: containers: - name: liveness-httpget-container image: httpd imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 livenessProbe: httpGet: port: http path: /index.html initialDelaySeconds: 1 periodSeconds: 3 timeoutSeconds: 10 检测是否存在/index.html文件，有则正常，没有则重启pod 来源： 51CTO 作者： 头发太长l 链接： https://blog.51cto.com/11954248/2477634

apiVersion: v1 kind: Pod metadata: name: liveness-tcp namespace: default spec: containers: - name: liveness-tcp-container image: httpd imagePullPolicy: IfNotPresent livenessProbe: initialDelaySeconds: 5 timeoutSeconds: 10 tcpSocket: port: 8080 periodSeconds: 3 镜像默认端口应该是80，但是yaml文件故意写成8080，tcp检测失败，pod会反复执行重启操作知道检测到80端口 来源： 51CTO 作者： 头发太长l 链接： https://blog.51cto.com/11954248/2477637

本文的演练环境为基于Virtualbox搭建的Kubernetes集群，具体搭建步骤可以参考 kubeadm安装kubernetes V1.11.1 集群 1. 基本概念 1.1 Pod是什么 Pod是Kubernetes中能够创建和部署的最小单元，是Kubernetes集群中的一个应用实例，总是部署在同一个节点Node上。Pod中包含了一个或多个容器，还包括了存储、网络等各个容器共享的资源。Pod支持多种容器环境，Docker则是最流行的容器环境。 单容器Pod，最常见的应用方式。 多容器Pod，对于多容器Pod，Kubernetes会保证所有的容器都在同一台物理主机或虚拟主机中运行。多容器Pod是相对高阶的使用方式，除非应用耦合特别严重，一般不推荐使用这种方式。一个Pod内的容器共享IP地址和端口范围，容器之间可以通过 localhost 互相访问。 Pod并不提供保证正常运行的能力，因为可能遭受Node节点的物理故障、网络分区等等的影响，整体的高可用是Kubernetes集群通过在集群内调度Node来实现的。通常情况下我们不要直接创建Pod，一般都是通过Controller来进行管理，但是了解Pod对于我们熟悉控制器非常有好处。 1.2 Pod带来的好处 Pod带来的好处 Pod做为一个可以独立运行的服务单元，简化了应用部署的难度，以更高的抽象层次为应用部署管提供了极大的方便

光纤交换机当前配置情况如下： switchshow switchName: swd77 switchType: 71.2 switchState: Online switchMode: Native switchRole: Principal switchDomain: 1 switchId: fffc01 switchWwn: 10:00:00:05:33:c9:62:95 zoning: ON (cfg_1) switchBeacon: OFF Index Port Address Media Speed State Proto ============================================== 0 0 010000 id N8 Online FC F-Port 50:06:0e:80:10:05:e3:d0 1 1 010100 id N4 Online FC F-Port 21:01:00:e0:8b:ae:e9:64 2 2 010200 id N8 Online FC F-Port 50:06:0e:80:10:05:e3:d8 3 3 010300 id N8 No_Light FC 4 4 010400 id N4 Online FC F-Port 21:00:00:24:ff:03:df:65 5 5 010500 id N4

一、删除node节点 1、先查看一下这个node节点上的pod信息 2、驱逐这个node节点上的pod # kubectl drain node06 --delete-local-data --force --ignore-daemonsets 3、删除这个node节点 # kubectl delete nodes node06 4、然后在node06这个节点上执行如下命令： kubeadm reset systemctl stop kubelet systemctl stop docker rm -rf /var/lib/cni/ rm -rf /var/lib/kubelet/* rm -rf /etc/cni/ ifconfig cni0 down ifconfig flannel.1 down ifconfig docker0 down ip link delete cni0 ip link delete flannel.1 systemctl start docker systemctl start kubelet 如果不做上面的操作的话会导致这个节点上的pod无法启动 ，具体报错信息为：networkPlugin cni failed to set up pod "alertmanager-main-1_monitoring" network: failed to

kubernetes 常用命令 通过yaml文件创建： kubectl create -f xxx.yaml （不建议使用，无法更新，必须先delete） kubectl apply -f xxx.yaml （创建+更新，可以重复使用） 通过yaml文件删除： kubectl delete -f xxx.yaml 查看kube-system namespace下面的pod/svc/deployment 等等（-o wide 选项可以查看存在哪个对应的节点） kubectl get pod/svc/deployment -n kube-system 查看所有namespace下面的pod/svc/deployment等等 kubectl get pod/svc/deployment --all-namcpaces 重启pod（无法删除对应的应用，因为存在deployment/rc之类的副本控制器，删除pod也会重新拉起来） kubectl get pod -n kube-system 查看pod描述： kubectl describe pod XXX -n kube-system 查看pod 日志 （如果pod有多个容器需要加-c 容器名） kubectl logs xxx -n kube-system 删除应用（先确定是由说明创建的，再删除对应的kind）： kubectl

从零开始入门 K8s | Kubernetes 网络模型进阶 https://www.kubernetes.org.cn/6838.html 2020-03-03 13:57 alicloudnative 分类： Kubernetes教程/入门教程 阅读(1130) 评论(0) 作者 | 叶磊（稻农）阿里巴巴高级技术专家 导读：本文将基于之前介绍的 基本网络模型 ，进行更深入的一些了解，希望给予读者一个更广更深的认知。首先简单回顾一下容器网络的历史沿革，剖析一下 Kubernetes 网络模型的由来；其次会剖析一个实际的实现（Flannel Hostgw），展现了数据包从容器到宿主机的变换过程；最后对于和网络息息相关的 Servcie 做了比较深入的机制和使用介绍，通过一个简单的例子说明了 Service 的工作原理。 Kubernetes 网络模型来龙去脉 容器网络发端于 Docker 的网络。Docker 使用了一个比较简单的网络模型，即内部的网桥加内部的保留 IP。这种设计的好处在于容器的网络和外部世界是解耦的，无需占用宿主机的 IP 或者宿主机的资源，完全是虚拟的。它的设计初衷是：当需要访问外部世界时，会采用 SNAT 这种方法来借用 Node 的 IP 去访问外面的服务。比如容器需要对外提供服务的时候，所用的是 DNAT 技术，也就是在 Node 上开一个端口，然后通过

第一章、前言 默认情况下容器的数据都是非持久化的， 在容器消亡以后数据也跟着丢失， 所以 Docker 提供了 Volume 机制以便将数据持久化存储。 类似的， Kubernetes 提供了更强大的 Volume 机制和丰富的插件， 解决了容器数据持久化和容器间共享数据的问题。 与 Docker 不同， Kubernetes Volume 的生命周期与 Pod 绑定容器挂掉后 Kubelet 再次重启容器时， Volume 的数据依然还在而 Pod 删除时， Volume 才会清理。 数据是否丢失取决于具体的 Volume 类型， 比如 emptyDir 的数据会丢失， 而 PV 的数据则不会丢 PersistentVolume（pv）和PersistentVolumeClaim（pvc）是k8s提供的两种API资源，用于抽象存储细节。管理员关注于如何通过pv提供存储功能而无需关注用户如何使用，同样的用户只需要挂载pvc到容器中而不需要关注存储卷采用何种技术实现。 pvc和pv的关系与pod和node关系类似，前者消耗后者的资源。pvc可以向pv申请指定大小的存储资源并设置访问模式。 第二章、pv pvc相关知识 生命周期 pv和pvc遵循以下生命周期： 1.供应准备。管理员在集群中创建多个pv供用户使用。 　2.绑定。用户创建pvc并指定需要的资源和访问模式。在找到可用pv之前

CocoaPods是一个负责管理iOS项目中第三方开源代码的工具。使用CocoaPods可以为我们节省设置和更新第三方开源库的时间。 下面将分为两部分来讲述如何安装和使用CocoaPods。 一、安装CocoaPods 先使用下面命令升级Ruby版本： ? 1 gem update --system 等待更新完成后，然后通过gem命令来下载安装CocoaPods： ? 1 gem install cocoapods 安装完毕后调用下面命令，进行CocoaPods设置： ? 1 pod setup 执行完成上述命令后，表示安装成功！下面将讲述如何使用CocoaPods。 二、使用CocoaPods 打开终端，使用cd命令定位到需要使用CocoaPods的项目根路径。如： ? 1 cd /Users/username/Documents/Projects/Demo 先考虑项目中需要引用哪些库，然后在通过search命令来查找库的信息，如需要加入JSONKit，那可以如下写法： ? 1 pod search JSONKit 命令执行后会得到如下结果： ? 1 2 3 4 5 6 -> JSONKit (1.5pre) A Very High Performance Objective-C JSON Library. pod 'JSONKit' , '~> 1.5pre' -

自动化运维 平台化(ansible、git、gitlab、docker、jenkins、elk) 自动化（工具/脚本） 容器化（docker/k8s） 虚拟化 docker和虚拟机的区别 更高效的资源利用。虚拟机是一个完备的系统，容器只是一个进程。 虚拟机启动慢，容器是秒级 一致的运行环境 CI/CD 容器核心概念 镜像Image （1）镜像是一个特殊的文件系统。它除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（例如环境变量）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。 （2）镜像采用的是AUFS，实现分层结构。镜像构建时，会一层层构建，前一层是后一层的基础。每一层构建完就不会再发生改变，后一层上的任何改变只发生在自己这一层。镜像是只读的。创建新镜像时，底层内容不变，只是给镜像增加了一个新层次。 容器Container （1）容器可以认为是镜像的一次执行，是可读写的镜像。容器只是操作系统上的一个进程，进程执行完毕将会退出。不要假定容器会一直存在，应该假设它随时会崩溃。容器一旦出现故障，不要犹豫，直接将它删除，再启动一个。 （2）按照 Docker 最佳实践的要求，容器不应该向其存储层内写入任何数据,容器存储层要保持无状态化。所有的文件写入操作，都应该使用 数据卷(Volume)、或者绑定宿主目录