精华内容
参与话题
问答
  • Kubernetes-核心资源之Pod

    千次阅读 2018-08-17 13:58:31
    1、Pod概述 在Kubernetes集群中,Pod是所有业务类型的基础,它是一个或多个容器的组合。这些容器共享存储、网络和命名空间,以及如何运行的规范。在Pod中,所有容器都被同一安排和调度,并运行在共享的上下文中。...

    1、Pod概述

    在Kubernetes集群中,Pod是所有业务类型的基础,它是一个或多个容器的组合。这些容器共享存储、网络和命名空间,以及如何运行的规范。在Pod中,所有容器都被同一安排和调度,并运行在共享的上下文中。对于具体应用而言,Pod是它们的逻辑主机,Pod包含业务相关的多个应用容器。Kubernetes不只是支持Docker容器,它也支持其他容器。Pod 的上下文可以理解成多个linux命名空间的联合:

    • PID 命名空间(同一个Pod中应用可以看到其它进程)
    • 网络 命名空间(同一个Pod的中的应用对相同的IP地址和端口有权限)
    • IPC 命名空间(同一个Pod中的应用可以通过VPC或者POSIX进行通信)
    • UTS 命名空间(同一个Pod中的应用共享一个主机名称)

    一个Pod的共享上下文是Linux命名空间、cgroups和其它潜在隔离内容的集合。 在Pod中,容器共享一个IP地址和端口空间,它们可以通过localhost发现彼此。在同一个Pod中的容器,可以使用System V 或POSIX信号进行标准的进程间通信和共享内存。在不同Pod中的容器,拥有不同的IP地址,因此不能够直接在进程间进行通信。容器间通常使用Pod IP地址进行通信。在一个Pod中的应用于口访问共享的存储卷,它被定为为Pod的一部分,可以被挂接至每一个应用文件系统。与独立的应用容器一样,Pod是一个临时的实体,它有着自己的生命周期。在Pod被创建时,会被指派一个唯一的ID,并被调度到Node中,直到Pod被终止或删除。如果Pod所在的Node宕机,给定的Pod(即通过UID定义)不会被重新调度。相反,它将被完全相同的Pod所替代。这所说的具有和Pod相关生命周期的情况,例如存储卷,是说和Pod存在的时间一样长。如果Pod被删除,即使完全相同的副本被创建,则相关存储卷等也会被删除,并会Pod创建一个新的存储卷等。Pod本身就没有打算作为持久化的实体,在调度失败、Node失败和获取其它退出(缺少资源或者Node在维护)情况下,Pod都会被删除。一般来说,用户不应该直接创建Pod,即是创建单个的Pod也应该通过控制器创建。在集群范围内,控制器为Pod提供自愈能力,以及副本和部署管理。

    一个多容器的Pod会包含一个文件拉取器和一个web服务器,此web服务器使用一个持久化存储卷来在容器中共享存储。

    网络:每一个Pod都会被指派一个唯一的Ip地址,在Pod中的每一个容器共享网络命名空间,包括Ip地址和网络端口。在同一个Pod中的容器可以同locahost进行互相通信。当Pod中的容器需要与Pod外的实体进行通信时,则需要通过端口等共享的网络资源。

    存储:Pod能够被指定共享存储卷的集合,在Pod中所有的容器能够访问共享存储卷,允许这些容器共享数据。存储卷也允许在一个Pod持久化数据,以防止其中的容器需要被重启。

    2Pod的工作方式

    在Kubernetes中一般不会直接创建一个独立的Pod,这是因为Pod是临时存在的一个实体。当直接创建一个独立的Pod时,如果缺少资源或者所被调度到的Node失败,则Pod会直接被删除。这里需要注意的是,重起Pod和重起Pod中的容器不是一个概念,Pod自身不会运行,它只是容器所运行的一个环境。Pod本身没有自愈能力,如果Pod所在的Node失败,或者如果调度操作本身失败,则Pod将会被删除;同样的,如果缺少资源,Pod也会失败。Kubernetes使用高层次的抽象,即控制器来管理临时的Pod。通过控制器能够创建和管理多个Pod,并在集群范围内处理副本、部署和提供自愈能力。例如,如果一个Node失败,控制器可以自动的在另外一个节点上部署一个完全一样的副本。控制器是Pod模板来创建Pod,Pod的控制器包括:

    Pod模板是一个被包含在其它对象(例如:Deployment、StatefuleSet、DaemonSet等)中的Pod规格。控制使用Pod模板创建实际的Pod,下面是Pod模板的一个示例:

    2.1 重启策略

    在Pod中的容器可能会由于异常等原因导致其终止退出,Kubernetes提供了重启策略以重启容器。重启策略对同一个Pod的所有容器起作用,容器的重启由Node上的kubelet执行。Pod支持三种重启策略,在配置文件中通过restartPolicy字段设置重启策略:

    • Always:只要退出就会重启。
    • OnFailure:只有在失败退出(exit code不等于0)时,才会重启。
    • Never:只要退出,就不再重启

    注意,这里的重启是指在Pod的宿主Node上进行本地重启,而不是调度到其它Node上。

    2.2 镜像拉取策略

    在Kubernetes中,容器的运行是基于容器镜像的。Pod支持三种镜像拉取策略,在配置文件中通过imagePullPolicy字体设置镜像的拉取策略

    • Always:不管本地是否存在镜像都会进行一次拉取。
    • Never:不管本地是否存在镜像都不会进行拉取。
    • IfNotPresent:仅在本地镜像不存在时,才会进行镜像拉取。

    注意:

    • 镜像拉取策略的默认值为IfNotPresent,但:latest标签的镜像默认为Always。
    • 拉取镜像时docker会进行校验,如果镜像中的MD5码没有变,则不会拉取镜像数据。
    • 生产环境中应该尽量避免使用:latest标签,而开发环境中可以借助:latest标签自动拉取最新的镜像。

    2.3 使用私钥镜像仓库

    在Kubernetes中运行容器时,需要为容器获取镜像。Pod中容器的镜像有三个来源,即Docker公共镜像仓库、私有镜像仓库和本地镜像。当在内网使用的Kubernetes场景下,就需要搭建和使用私有镜像仓库。在使用私有镜像拉取镜像时,需要为私有镜像仓库创建一个docker registry secret,并在创建容器中进行引用。

    通过kubectl create secret docker-registry命令创建docker registry secret:

    $ kubectl create secret docker-registry regsecret --docker-server=<your-registry-server> \
    --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>

    在容器中通过imagePullSecrets字段指定该secret:

    2.4 资源限制

    Kubernetes通过cgroups来限制容器的CPU和内存等计算资源,在创建Pod时,可以为Pod中的每个容器设置资源请求(request)和资源限制(limit),资源请求是容器需要的最小资源要求,资源限制为容器所能使用的资源上限。CPU的单位是核(core),内存(Memory)的单位是字节(byte)。在Pod中,容器的资源限制通过resources.limits进行设置:

    • spec.containers[].resources.limits.cpu:容器的CPU资源上限,可以短暂超过,容器也不会被停止;
    • spec.containers[].resources.limits.memory:容器的内存资源上限,不可以超过;如果超过,容器可能会被停止或调度到其它资源充足的Node上。

    资源请求通过resources.requests进行设置,

    • spec.containers[].resources.requests.cpu:容器的CPU资源请求,可以超过;
    • spec.containers[].resources.requests.memory:容器的内存资源请求,可以超过;但如果超过,容器可能会在Node内存不足时清理。

    Kubernetes在进行Pod调度时,Pod的资源请求是最重要的一个指标。Kubernetes Schedule会检查Node是否存在足够的资源,判断是否能够满足Pod的资源请求,从而决定是否可以运行Pod。

    2.5 健康检查

    在Pod部署到Kubernetes集群中以后,为了确保Pod处于健康正常的运行状态,Kubernetes提供了两种探针,用于检测容器的状态:

    • Liveness Probe :检查容器是否处于运行状态。如果检测失败,kubelet将会杀掉掉容器,并根据重启策略进行下一步的操作。如果容器没有提供Liveness Probe,则默认状态为Success;
    • ReadinessProbe :检查容器是否已经处于可接受服务请求的状态。如果Readiness Probe失败,端点控制器将会从服务端点(与Pod匹配的)中移除容器的IP地址。Readiness的默认值为Failure,如果一个容器未提供Readiness,则默认是Success。

    kubelet在容器上周期性的执行探针以检测容器的健康状态,kubelet通过调用被容器实现的处理器来实现检测,在Kubernetes中有三类处理器:

    • ExecAction :在容器中执行一个指定的命令。如果命令的退出状态为0,则判断认为是成功的;
    • TCPSocketAction :在容器IP地址的特定端口上执行一个TCP检查,如果端口处于打开状态,则视为成功;
    • HTTPGetAcction :在容器IP地址的特定端口和路径上执行一个HTTP Get请求使用container的IP地址和指定的端口以及请求的路径作为url,用户可以通过host参数设置请求的地址,通过scheme参数设置协议类型(HTTP、HTTPS)如果其响应代码在200~400之间,设为成功。

    健康检测的结果为下面三种情况:

    • Success :表示容器通过检测
    • Failure :表示容器没有通过检测
    • Unknown :表示容器容器失败

    2.6 初始化容器

    在一个POD中,可以运行多个容器,同时它也可以拥有有一个或多个初始化容器,初始化容器在应用程序容器启动之前运行。初始化容器与普通容器完全一样,只是:

    • 它们总是完全执行
    • 每一个初始化容器都必须在下一个初始化开始之前成功完成

    如果Pod中的初始化容器失败,Kubernetes将会重复重启Pod,直到初始化容器成功执行。然而,如果Pod的重启策略为Never,则Pod不会重启。初始化容器支持应用程序容器的所有字段和特性,包括资源限制、存储卷和安全设置等。初始化容器不支持健康检测探针,因为,它们必须在POD准备好之前完成运行。如果为Pod指定了多个初始化容器,则这些初始化容器将会按顺序依次运行。每一个都必须在下一个运行之前成功运行。当所有的初始化容器都运行完成时,Kubernetes完成Pod的初始化,并像通常的方式一样运行应用程序容器。

    2.7 容器调度

    Kubernetes Scheduler负责根据调度策略自动将Pod部署到合适Node中,调度策略分为预选策略和优选策略,Pod的整个调度过程分为两步:

    1)预选Node:遍历集群中所有的Node,按照具体的预选策略筛选出符合要求的Node列表。如没有Node符合预选策略规则,该Pod就会被挂起,直到集群中出现符合要求的Node。

    2)优选Node:预选Node列表的基础上,按照优选策略为待选的Node进行打分和排序,从中获取最优Node。

    2.7.1 预选策略

    随着版本的发展,Kunbernetes提供了大量的预选策略,通过预选策略能够筛选出符合条件的Node列表。预选策略是强制性规则,用来检测Node是否匹配Pod所需要的资源。如果没有任何Node能够满足预选策略, 该Pod就会被挂起,直到出现能够能够满足要求的Node。

    Position 预选策略 策略说明
    1 CheckNodeConditionPredicate 检查是否可以将Pod调度到磁盘不足、网络不可用和未准备就绪的Node。
    2 PodFitsHost 检查集群Node中是否存在与Pod配置文件中指定的Node名称相匹配。
    3 PodFitsHostPorts 检查Node是否存在空闲可用的端口。
    4 PodMatchNodeSelector 检查Pod上的Node选择器是否匹配Node的标签。
    5 PodFitsResources 检查Node上的cpu、内存、gpu等资源是否满足Pod的需求,来决定是否调度Pod到Node上。
    6 NoDiskConflict 根据Pod请求的存储卷进行评估,如果在这个Node已经挂载了存储卷,则其它同样请求这个存储卷的Pod将不能调度到这个Nods上。
    7 PodToleratesNodeTaints 检查pod的能否容忍Node上的污点。
    8 PodToleratesNodeNoExecuteTaints 检查Pod是否能容忍Node上未执行的污染。
    9 CheckNodeLabelPresence 检查所有指定的标签是否存在于Node上,而不考虑它们的值。
    10 checkServiceAffinity 检查服务的亲和性,确定是否在Node部署Pod。
    11 MaxPDVolumeCountPredicate 检查Pod所需要的存储卷的数量,确定在哪个Node上部署Pod。
    12 VolumeZonePredicate 根据volumes需求来评估Node是否满足条件。
    13 CheckNodeMemoryPressurePredicate 检查Node内存的压力情况
    14 CheckNodeDiskPressurePredicate 根据Node磁盘的压力情况,确定是否调度Pod到Node上。
    15 InterPodAffinityMatches 根据Pod的亲和和反亲和的配置,检查是否能够将Pod调度到指定的Node上。

     

    2.7.2 优选策略

    通过预选策略对Node过滤后,获得预选的Node列表。在预选Node列表的基础上,对这些预选的Node进行打分,从而为Pod选择一个分值最高的Node。Kubernetes通过一系列的优选策略对预选Node进行打分。每一个优选函数都会为Node给出一个0-10的分数,分数越高表示节点越优;同时,每个优选函数也会有一个对应的权重值。那个Node的最终得分是每个优选函数给出的得分的加权分数之和,因此每个Node的最终主机的得分如以下公式计算:

    finalScoreNode = (weight1 * priorityFunc1) + (weight2 * priorityFunc2) + … + (weightn * priorityFuncn)
    序号 优选策略 优选说明
    1 BalancedResourceAllocation 根据Node上各项资源(CPU、内存)使用率均衡情况进行打分。
    2 ImageLocalityPriority 基于Pod所需镜像的总体大小,根据Node上存在Pod所需镜像的大小从0到10进行打分。
    3 InterPodAffinityPriority 基于Pod亲和情况打分。
    4 LeastRequestedPriority 计算Pod需要的CPU和内存资源与在Node可用资源的百分比,具有最小百分比的节点就是最优。
    5 PriorityMetadata 根据元素进行打分。
    6 MostRequestedPriority 根据Node上所提供的资源进行打分。
    7 NodeAffinityPriority 根据亲和情况进行打分。
    8 NodeLabelPriority 根据Node上是否存在特殊的标签进行打分。
    9 NodePreferAvoidPodsPriority 根据Node上的注释进行打分。
    10 ResourceAllocationPriority 根据在Node上的分配的资源进行打分。
    11 ResourceLimitsPriority 根据Pod的资源限制进行打分。
    12 SelectorSpreadPriority 按service,RC,RS or StatefulSet归属

     

    计算Node上分布最少的同类Pod数量,得分计算,数量越少得分越高。

    13 TaintTolerationPriority 基于Node上不可容忍的污点数进行打分。

    2.7.3 将Pod分配给Node

    您可以约束一个POD,以便只能在特定节点上运行,或者更喜欢在特定节点上运行。有几种方法可以做到这一点,它们都使用标签选择器来进行选择。一般来说,这样的约束是不必要的,因为调度器将自动地进行合理的放置(例如,将您的荚散布在节点上,而不是将POD放置在自由资源不足的节点上),但是在某些情况下,您可能希望在POD L的节点上进行更多的控制。ODS,例如,确保POD在带有SSD的机器上结束,或者将两个不同服务的POD定位到相同的可用性区域中。

    2.7.3.1 nodeSelector

    nodeSelector是最简单一种约束形式,nodeSelector是PodSpec的一个字段。为了使Pod能够在Node上运行,Node必须具有所指示的键值对作为标签(它也可以有附加的标签)。nodeSeletor的用法如下:

    1)为Node打上标签

    $ kubectl label nodes <node-name> <label-key>=<label-value>

    2)在Pod配置文件中添加nodeSelector字段

    apiVersion: v1
    kind: Pod
    metadata: 
      name: nginx 
      labels: 
        env: test
      spec: 
        containers: 
        - name: nginx 
          image: nginx 
          imagePullPolicy: IfNotPresent
        nodeSelector: 
          disktype: ssd

    3)创建Pod,并将Pod调度到Node上

    通过执行如下命令,在集群中将会创建Pod,并在后台会将其调度到打上了键值对的Node上。

    $ kubectl create -f nginx.yaml

    通过下面的命令,可以查看Pod调度的情况

    $ kubectl get pods -o wide

    2.7.3.2 nodeName

    1)在Pod的配置文件中添加nodeName字段

    apiVersion: v1
    kind: Pod
    metadata: 
      name: nginx 
      labels: 
        env: test
    spec: 
      containers: 
      - name: nginx 
        image: nginx 
        imagePullPolicy: IfNotPresent
      nodeName: <NodeName>

    2)创建Pod,并将Pod调度到Node上

    通过执行如下命令,在集群中将会创建Pod,并在后台会将其调度到所指定的Node上。

    $ kubectl create -f nginx.yaml

    通过下面的命令,可以查看Pod调度的情况

    $ kubectl get pods -o wide

    2.8 环境变量

    在创建Pod时,可以为在Pod中运行的容器设置环境变量。在Kubernetes中,通过envenvFrom字段进行设置。使用envenvFrom字段设置的环境变量将会覆盖容器镜像中指定的环境变量。在下面的YAML文件中,设置了名称为DEMO_GREETINGDEMO_FAREWELL的两个环境变量。

    apiVersion: v1
    kind: Pod
    metadata: 
      name: envar-demo 
      labels: purpose: demonstrate-envars
    spec: 
      containers: 
      - name: envar-demo-container 
        image: gcr.io/google-samples/node-hello:1.0 
        env: 
        - name: DEMO_GREETING 
          value: "Hello from the environment" 
        - name: DEMO_FAREWELL 
          value: "Such a sweet sorrow"

    2.9 启动命令

    在创建Pod时,也能够为Pod中的容器定义命令和参数。在配置文件通过设置command字段来定义命令,通过设置args字段来定义参数。在Pod被创建后,定义的命令和参数将不能被修改。在配置文件中定义的命令和参数会覆盖在容器镜像中定义的命令和参数。下面的YAML配置文件中,设置了printenv命令,以及设置了HOSTNAMEKUBERNETES_PORT两个参数。

    apiVersion: v1
    kind: Pod
    metadata: 
      name: command-demo 
      labels: 
        purpose: demonstrate-command
    spec: 
      containers: 
      - name: command-demo-container 
        image: debian 
        command: ["printenv"] 
        args: ["HOSTNAME", "KUBERNETES_PORT"] 
      restartPolicy: OnFailure

    1)通过上述YAML配置文件参加Pod:

    $ kubectl create -f https://k8s.io/docs/tasks/inject-data-application/commands.yaml

    2)以列表的形式展示正在运行的Pod:

    $ kubectl get pods

    3)可以通过Pod的日志信息,参看命令的输出结果:

    $ kubectl logs command-demo

    输出结果显示了HOSTNAME和KUBERNETES_PORT环境变量的值:

    command-demo tcp://10.3.240.1:443

    在前面的例子中,通过提供字符串直接定义了参数,在参数中也可以使用环境变量来定义参数:

    env:
    - name: MESSAGE 
      value: "hello world"
    command: ["/bin/echo"]args: ["$(MESSAGE)"]

    这意味可以使用所有任意的技术变量(用于定义环境变量的)来定义Pod的参数,包括ConfigMaps和Secrets。在参数中,环境变量以”$(VAR)“的格式出现。

    3Pod的基本操作

    3.1 创建Pod

    按照Kubernetes的设计,Pod一般不独立进行创建,这是因为独立创建的Pod没有自愈能力,也就说在Pod异常终止后,无法进行自动重启和重新调度。

    1) 通过执行kubectl create -f命令创建名为nginx的部署和Pod:

    $ kubectl create -f nginx.yml

    2)通过执行kubectl get pods命令,可以看到在Kubernetes中运行了的nginx的Pod:

    $ kubectl get pods

    3.2 查看Pod信息

    在Pod被创建出来以后,可以通过如下的命令查看特定Pod的信息:

    $ kubectl describe pods/nginx-8566d78dc7-q4frr

    3.3 终止Pod

    在集群中,Pod代表着运行的进程,但不再需要这些进程时,如何优雅的终止这些进程是非常重要。以防止在Pod被暴力删除时,没有对Pod相关的信息进行必要的清除。当用户请求删除一个Pod时,Kubernetes将会发送一个终止(TERM)信号给每个容器,一旦过了优雅期,杀掉(KILL)信号将会被发送,并通过API server删除Pod。可以通过kubectl delete pod/{Pod名称} -n {命名空间名称}删除特定的Pod,一个终止Pod的流程如下:

    1) 用户可以通过kubectl、dashboard等发送一个删除Pod的命令,默认优雅的退出时间为30秒;

    2)更新API server中Pod的优雅时间,超过该时间的Pod会被认为死亡;

    3)在客户端命令行中,此Pod的状态显示为”Terminating(退出中)”;

    4)(与第3步同时)当Kubelet检查到Pod的状态退出中的时候,它将开始关闭Pod的流程:

      • 如果该Pod定义了一个停止前的钩子(preStop hook),其会在Pod内部被调用。如果超出优雅退出时间,钩子仍然还在运行,就会对第2步的优雅时间进行一个小的延长(一般为2秒)
      • 发送TERM的信号给Pod中的进程

    5)(与第3步同时进行)从服务的端点列表中删除Pod,对于副本控制器来说,此Pod将不再被认为是运行着的Pod的一部分。缓慢关闭的pod可以继续对外服务,直到负载均衡器将其移除。

    6.)当超过优雅的退出时间,在Pod中任何正在运行的进程都会被发送被杀死。

    7)Kubelet完成Pod的删除,并将优雅的退出时间设置为0。此时会将Pod删除,在客户端将不可见。

    在默认情况下,Kubernetes集群所有的删除操作的优雅退出时间都为30秒。kubectl delete命令支持–graceperiod=的选项,以支持用户来设置优雅退出的时间。0表示删除立即执行,即立即从API中删除现有的pod,同时一个新的pod会被创建。实际上,就算是被设置了立即结束的的Pod,Kubernetes仍然会给一个很短的优雅退出时间段,才会开始强制将其杀死。

    4、Pod的生命周期

    Pod的生命周期包括:从Pod被创建、并调度到Node中、以及Pod成功或失败的终止。Pod的阶段是一个简单的、高层次的Pod所处在生命周期的概述。在Pod的生命周期中,有如下的几个状态:

    • Pending: Pod已经被Kubernetes系统接受,但是还有一个或者多个容器镜像未被创建。这包括Pod正在被调度和从网络上下载镜像的时间。
    • Running: Pod已经被绑定到了一个Node,所有的容器也已经被创建。至少有一个容器已经在运行,或者在启动或者重新启动的过程中。
    • Succeeded: 在Pod中的所有的容器都已经被成功的终止,并且不会再重启。
    • Failed: 在Pod中所有容器都已经被终止,并且至少有一个容器是非正常终止的。即,容器以非零状态退出或者被系统强行终止的。
    • Unknown: 由于某些原因,Pod不能被获取,典型的情况是在与Pod的主机进行通信中发生了失败。

    在Pod的规格中有一个restartPolicy属性,它的值包括:Always, OnFailure和Never。

    • Always:当容器终止退出后,总是会重启容器,这是默认值;
    • OnFailure:只有在容器非正常退出时,才会重启容器。
    • Never:不管容器是否正常退出,都不再重启容器。

    5、参考材料

    1.《Pull an Image from a Private Registry》地址:https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/

    2.《Kubernetes调度详解》作者:张夏 地址:http://dockone.io/article/2885

    3.《predicates.go》地址:https://github.com/kubernetes/kubernetes/blob/master/pkg/scheduler/algorithm/predicates/predicates.go

    4.《Define Environment Variables for a Container》地址:https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/

    5.《Define a Command and Arguments for a Container》地址:https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/

    6.《Pod Lifecycle》地址:https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle

    7.《Init Containers》地址:https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

    8.《Configure Pod Initialization》地址:https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-initialization/

    9.《Assign CPU Resources to Containers and Pods》地址:https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/

    10.《Assign Memory Resources to Containers and Pods》地址:https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/

    11.《Configure Liveness and Readiness Probes》地址:https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

    12.《predicates ordering》地址:https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/predicates-ordering.md

    13.《priorities》地址:https://github.com/kubernetes/kubernetes/tree/master/pkg/scheduler/algorithm/priorities

    14.《Assigning Pods to Nodes》地址:https://kubernetes.io/docs/concepts/configuration/assign-pod-node/

    15.《Pod Overview》地址:https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/

    展开全文
  • pod 的详细介绍及使用

    千次阅读 2016-10-25 10:26:49
    pod setup 用于初始化本地第三方库的Spec描述文件,所有的spec文件存都存放在 ~/.cocoapods 目录中。 pod install 用来安装或删除Podfile文件声明中的第三方依赖库。下面继续介绍其它一些命令。 ...
    pod setup
    
    用于初始化本地第三方库的Spec描述文件,所有的spec文件存都存放在
    ~/.cocoapods
    目录中。
    pod install
    用来安装或删除Podfile文件声明中的第三方依赖库。下面继续介绍其它一些命令。
    1. $ pod list
    2. # 列出所有可用的第三方库
    复制代码
    1. $ pod search query
    复制代码
    搜索名称包含query的类库,query可以替换为你想搜索的名字(如json),不区分大小写。也可以使用pod search --full query命令作更仔细的搜索,该命令不但搜索类库的名称,同时还搜索类库的描述文本,所以搜索速度也相对慢一些。 

    pod listpod search命令只搜索存在于本地~/.cocoapods文件夹的所有第三方库,并不会连接到远程服务器。如果你要从服务器更新本地第三方库的描述文件,可以:
    1. $ pod repo update master
    2. 创建自己项目的Podspec描述文件
    复制代码
    CocoaPods还是一个相对年轻的项目,所有的项目的Podspec文件都托管在 。可能有一些库并未收录其中。下面我们通过为微博sso认证登录库编写Podspec文件来学习相关的概念。 

    初始化一个Podspec文件
    1. $ pod spec create weibo_ios_sdk_sso-oauth
    复制代码
    该命令将在本目录产生一个名为weibo_ios_sdk_sso-oauth.podspec的文件。用编辑器打开该文件,里面已经有非常丰富的说明文档。下面我们介绍如何声明第三方库的代码目录和资源目录,还有该第三方库所依赖ios核心框架和第三方库。 

    去除所有的注释,podspec文件如下所示:
    1. Pod::Spec.new do |s|
    2. s.name = 'ADVProgressBar'
    3. s.version = '0.0.1'
    4. s.license = 'MIT'
    5. s.summary = 'Progress Bar Design with Percentage values.'
    6. s.homepage = 'https://github.com/appdesignvault'
    7. s.author = { 'appdesignvault' => 'appdesignvault' }
    8. s.source = { :git => 'https://github.com/appdesignvault/ADVProgressBar.git', :commit => 'f17b15c15574d6d101cd5fcfd58239e16e806647' }
    9. s.platform = :ios 
    10. s.source_files = 'ADVProgressBar/Classes/*.{h,m}'
    11. s.resources = "ADVProgressBar/Resources/*.png"
    12. s.framework = 'UIKit'

    13. s.requires_arc = true 
    14. end
    复制代码
    其中s.names.summary用来声明库的名称和一个简短的说明文档。pod search命令就是根据这两项内容作为搜索文本的。s.homepage声明库的主页,s.version库原代码的版本,s.license所采用的授权版本,s.author库的作者。 

    s.source 声明原代码的地址,以微博sso认证登录库为例,它托管在
    1. https://github.com/mobileresearch/weibo_ios_sdk_sso-oauth
    复制代码
    中,在其未尾加上.git扩展名就是库的原代码地址了,所以该行应声明为:
    1. s.source = { :git => 'https://github.com/mobileresearch/weibo_ios_sdk_sso-oauth.git'}
    复制代码
    对于很多第三方库而言,在发布的时候都会打上一个tag,如版本0.0.1就会打上一个名为v0.0.1的tag,但是weibo_ios_sdk_sso-oauth库还未打上所何tag,我们可以选择一个最新的commit来作为该库0.0.1版的代码。s.source最终如下:
    1. s.source = { :git => 'https://github.com/mobileresearch/weibo_ios_sdk_sso-oauth.git', :commit => '68defea78942ecc782ffde8f8ffa747872af226d'}
    复制代码
    以后我们可以根据该库不同的版本创建相应的podspec文件,例如0.0.2,0.1.0等。 

    让我们在浏览器中看一下weibo_ios_sdk_sso-oauth的目录结构:
    1. --
    2. |
    3. +-- demo
    4. |
    5. +-- src
    6. |
    7. +-- .gitignore
    8. |
    9. +-- README.md
    复制代码
    demo目录保存一个示例项目,src才是库的原代码目录。src的目录结构如下:
    1. -- src
    2. |
    3. +-- JSONKit
    4. |
    5. +-- SinaWeibo
    6. |
    7. +-- sinaweibo_ios_sdk.xcodeproj
    8. |
    9. +-- SinaWeibo-Prefix.pch
    复制代码
    JSONKit目录说明这个库本身依赖于JSONKit第三方库。我们可以在podspec文件中的s.dependency声明段中声明。SinaWeibo目录才是包含所有原代码的目录,我们需要在s.source_files中声明
    1. s.source_files = 'src/SinaWeibo/*.{h,m}'
    复制代码
    前一部分src/SinaWeibo/是一个相对目录,目录的层级关系一定要跟代码库的保持一致。最后一部分*.{h,m}是一个类似正则表达式的字符串,表示匹配所有以.h和.m为扩展名的文件。 

    src/SinaWeibo/目录下还有一个SinaWeibo.bundle目录,该目录存放一些资源文件(如图片等),这些文件并不需要进行编译。可以使用s.resourcs声明
    1. s.resources = "src/SinaWeibo/SinaWeibo.bundle/**/*.png"
    复制代码
    前一部分跟上面相同,**表示匹配所有子目录,*.png表示所有以.png为扩展名的图片文件。 

    通过查看代码我们知道,weibo_ios_sdk_sso-oauth还依赖一个ios的核心库QuartzCore
    1. s.framework = 'QuartzCore'
    复制代码
    在前面我们已经说过,weibo_ios_sdk_sso-oauth库自身也依赖于另外一个第三方库JSONKit,声明如下:
    1. s.dependency 'JSONKit', '~> 1.4'
    复制代码
    这行声明与Podfile文件中的声明类似。 

    最终的结果如下:
    1. Pod::Spec.new do |s|
    2. s.name = "weibo_ios_sdk_sso-oauth"
    3. s.version = "0.0.1"
    4. s.summary = 'weibo.com sso oauth, 微博sso认证登录功能'
    5. s.homepage = "https://github.com/mobileresearch/weibo_ios_sdk_sso-oauth"
    6. s.license = 'MIT'
    7. s.author = {'mobileresearch' => 'mobileresearch'}
    8. s.source = { :git => 'https://github.com/mobileresearch/weibo_ios_sdk_sso-oauth.git', :commit => '68defea78942ecc782ffde8f8ffa747872af226d' }
    9. s.platform = :ios
    10. s.source_files = 'src/SinaWeibo/*.{h,m}'
    11. s.resources = "src/SinaWeibo/SinaWeibo.bundle/**/*.png"
    12. s.framework = 'QuartzCore'
    13. s.dependency 'JSONKit', '~> 1.4'
    14. end
    复制代码
    可以将该spec文件保存到本机的~/.cocoapods/master/目录中仅供自己使用,也可以将其提交到CocoaPods/Specs代码库中。下面我们将其保存到本机中
    1. $ mkdir -p ~/.cocoapods/master/weibo_ios_sdk_sso-oauth/0.0.1
    2. $ cp weibo_ios_sdk_sso-oauth.podspec ~/.cocoapods/master/weibo_ios_sdk_sso-oauth/0.0.1
    复制代码
    是否可以通过搜索找到该库:
    1. $ pod search weibo
    复制代码
    同样在需要依赖于weibo_ios_sdk_sso-oauth这个库的项目,可以将下列添加到项目的Podfile文件中
    1. pod 'weibo_ios_sdk_sso_oauth', '0.0.1'
    复制代码
    保存文件,并用pod install安装weibo_ios_sdk_sso-oauth库。 

    接着我们回到Xcode proj所在的文件夹中,编辑Podfile,添加pod 'ChartboostSDK', :local => '~/Desktop/ChartboostSDK'。这里的local表明从本地的Git仓库里获取代码。

    最后我们运行pod update,大功告成。

    CocoaPods小结

    上面的两种情况,简单来说:

    • 需要使用最新的开源代码/库,但没最新的spec
    • 需要使用私有代码/库,需要对应的私有的spec

    对于第一种情况,建议大家可以给CocoaPods / Specs提交一个pull request。

    使用CocoaPods只需要知道两件事情:

    • podspec:一个pod的配置是什么,pod的代码放在哪里
    • Podfile:项目依赖哪个pod,以何种方式依赖,它的podspec放在哪里

    这里podspec和git repository都非常灵活,可以放在本地,也可以放到github/gist上。代码仓库甚至可以不使用git而直接使用一个zip压缩包。

    使用CocoaPods可以把多们从繁重的配置和代码管理中解脱出来,而且可以少犯错误。比如Deployment Target设置为5.0,但App中需要使用AdSupport.framework,如果忘记设置为optional则所有5.x的设备运行时都会crash。对于这种情况CocoaPods在spec提供了weak_frameworks的配置选项。同时CocoaPods能够保证库的依赖关系,而不会出现几个项目依赖版本不一致的情况。

    CocoaPods详解之----制作篇 作者:wangzz 原文地址:http://blog.csdn.net/wzzvictory/article/details/20067595 转载请注明出处 如果觉得文章对你有所帮助,请通过留言或关注微信公众帐号wangzzstrive来支持我,谢谢!
    学会使用别人的Pods依赖库以后,你一定对创建自己的依赖库跃跃欲试,今天就来揭开Pods依赖库创建过程的神秘面纱。整个创建过程都以我实现的一个名称为WZMarqueeView跑马灯效果的view为例,步骤如下:

    一、创建自己的github仓库

    CocoaPods都托管在github上(官方链接为:https://github.com/CocoaPods),所有的Pods依赖库也都依赖github,因此第一步我们需要创建一个属于自己的github仓库。仓库创建界面如下图: \
    上图中标了序号的共6处,对应的说明如下: 1、Repository name 仓库名称,这里写成WZMarqueeView,必填的; 2、Description 仓库的描述信息,可选的; 3、仓库的公开性 这里只能选Public,一个是因为Private是要money的,再一个Private别人看不到还共享个毛; 4、是否创建一个默认的README文件 一个完整地仓库,都需要README说明文档,建议选上。当然不嫌麻烦的话你也可以后面再手动创建一个; 5、是否添加.gitignore文件 .gitignore文件里面记录了若干中文件类型,凡是该文件包含的文件类型,git都不会将其纳入到版本管理中。是否选择看个人需要; 6、license类型 正规的仓库都应该有一个license文件,Pods依赖库对这个文件的要求更严,是必须要有的。因此最好在这里让github创建一个,也可以自己后续再创建。我使用的license类型是MIT。
    上面的各项都填写完毕后,点击Create repository按钮即可,创建成功地界面如图: \
    到这,仓库创建过程就结束了。

    二、clone仓库到本地

    为了便于向仓库中删减内容,需要先将仓库clone到本地,操作方式有多种,推荐使用命令行:
    1.$ git clone https://github.com/wangzz/WZMarqueeView.git
    操作完成后,github上对应的文件都会拷贝到本地,目录结构为: \
    github上仓库中的.gitignore文件是以.开头的隐藏文件,因此这里只能看到两个。 后续我们的所有文件增、删、改都在这个目录下进行。

    三、向本地git仓库中添加创建Pods依赖库所需文件

    注意:以下描述的文件都要放在步骤二clone到本地的git仓库的根目录下面。

    1、后缀为.podspec文件

    该文件为Pods依赖库的描述文件,每个Pods依赖库必须有且仅有那么一个描述文件。文件名称要和我们想创建的依赖库名称保持一致,我的WZMarqueeView依赖库对应的文件名为WZMarqueeView.podspec。

    1.1 podspec文件内容

    WZMarqueeView.podspec的保存内容为:
    01.Pod::Spec.new do |s|
    02.s.name             = "WZMarqueeView"
    03.s.version          = "1.0.0"
    04.s.summary          = "A marquee view used on iOS."
    05.s.description      = <<-DESC
    06.It is a marquee view used on iOS, which implement by Objective-C.
    07.DESC
    08.s.homepage         = "https://github.com/wangzz/WZMarqueeView"
    09.# s.screenshots      = "www.example.com/screenshots_1""www.example.com/screenshots_2"
    10.s.license          = 'MIT'
    11.s.author           = { "王中周" => "wzzvictory_tjsd@163.com" }
    12.s.source           = { :git => "https://github.com/wangzz/WZMarqueeView.git", :tag => s.version.to_s }
    13.# s.social_media_url = 'https://twitter.com/NAME'
    14. 
    15.s.platform     = :ios, '4.3'
    16.# s.ios.deployment_target = '5.0'
    17.# s.osx.deployment_target = '10.7'
    18.s.requires_arc = true
    19. 
    20.s.source_files = 'WZMarqueeView/*'
    21.# s.resources = 'Assets'
    22. 
    23.# s.ios.exclude_files = 'Classes/osx'
    24.# s.osx.exclude_files = 'Classes/ios'
    25.# s.public_header_files = 'Classes/**/*.h'
    26.s.frameworks = 'Foundation''CoreGraphics''UIKit'
    27. 
    28.end
    该文件是ruby文件,里面的条目都很容易知道含义。 其中需要说明的又几个参数: ①s.license Pods依赖库使用的license类型,大家填上自己对应的选择即可。 ②s.source_files 表示源文件的路径,注意这个路径是相对podspec文件而言的。 ③s.frameworks 需要用到的frameworks,不需要加.frameworks后缀。

    1.2 如何创建podspec文件

    大家创建自己的podspec文件可以有两个途径: ①copy我的podspec文件然后修改对应的参数,推荐使用这种方式。 ②执行以下创建命令:
    1.$ pod spec create WZMarqueeView
    也会创建名为WZMarqueeView.podspec的文件。但是打开创建完的文件你就会发现里面的东西太多了,很多都是我们不需要的。

    2、LICENSE文件

    CocoaPods强制要求所有的Pods依赖库都必须有license文件,否则验证不会通过。license的类型有很多种,详情可以参考网站tl;dr Legal。在创建github仓库的时候,我已经选择了MIT类型的license。

    3、主类文件

    创建Pods依赖库就是为了方便别人使用我们的成果,比如我想共享给大家的WZMarqueeView类,是我想提供给广大用户使用的,这个类自然是必不可少的。我把这个类包含的两个文件放到一个名称为WZMarqueeView的文件夹中,对应的目录结构如图: \
    里面包含两个文件:WZMarqueeView.h和WZMarqueeView.m

    4、demo工程

    为了快速地教会别人使用我们的Pods依赖库,通常需要提供一个demo工程。我创建的demo工程放到了一个名为WZMarqueeViewDemo的文件夹中,该目录包含的文件如下图所示: \

    5、README.md

    使用github的人应该都熟悉这个文件,它是一个成功github仓库必不可少的一部分,使用的是markdown标记语言,用于对仓库的详细说明。
    以上所说的5个是创建Pods依赖库所需最基础的文件,其中1、2、3是必需的,4、5是可选但强烈推荐创建的。 添加完这些文件以后,我的github本地仓库目录就变成了下图所示的样子: \

    四、提交修改文件到github

    经过步骤三,向本地的git仓库中添加了不少文件,现在需要将它们提交到github仓库中去。提交过程分以下几步:

    1、pod验证

    执行以下命令:
    1.$ set the new version to 1.0.0
    2.$ set the new tag to 1.0.0
    这两条命令是为pod添加版本号并打上tag。然后执行pod验证命令:
    1.$ pod lib lint
    如果一切正常,这条命令执行完后会出现下面的输出:
    1.-> WZMarqueeView (1.0.0)
    2. 
    3.WZMarqueeView passed validation.
    到此,pod验证就结束了。 需要说明的是,在执行pod验证命令的时候,打印出了任何warning或者error信息,验证都会失败!如果验证出现异常,打印的信息会很详细,大家可以根据对应提示做出修改。

    2、本地git仓库修改内容上传到github仓库

    依次执行以下命令:
    1.$ git add -A && git commit -m "Release 1.0.0."
    2.$ git tag '1.0.0'
    3.$ git push --tags
    4.$ git push origin master
    上述命令均属git的范畴,这里不多述。如果一切正常,github上就应该能看到自己刚添加的内容了。如下图所示: \


    五、上传podspec文件到CocoaPods官方仓库中

    经过前边的四步操作,你可能以为已经结束了,不幸的是还早着呢。 要想一个Pods依赖库真正可用,还需要做最后一步操作,将我们刚才生成的podspec文件上传到CocoaPods官方的Specs仓库中,链接为:https://github.com/CocoaPods/Specs 打开这个链接你就会发现,原来我们能使用的,以及我们使用pod search命令能搜索到的所有Pods依赖库都会把它们的podspec文件上传到这个仓库中,也就是说,只有将我们的podspec文件上传到这个仓库中以后,才能成为一个真正的Pods依赖库,别人才能正常使用! 按照git的规则,要想向别人的仓库中添加文件,必须先fork一份别人的仓库,做完相应地修改后,在push给仓库的原作者,等到作者审核通过,然后合并到原来的仓库中。 流程明白了以后,自然知道该怎么干了:

    1、fork一份CocoaPods官方的Specs仓库

    进入到刚才的官方仓库链接中,点击屏幕右上角的fork按钮,如下图: \

    然后大家会发现自己名下会多一份仓库的分支。比如我的分支为: \

    2、将fork的仓库clone到本地

    执行以下命令:
    1.$ git clone https://github.com/wangzz/Specs.git
    注意,大家需要将对应的仓库地址换成自己的。 这个仓库有点大,需要有耐心啊。

    3、将自己的podspec文件添加到本地Specs仓库中

    Specs仓库clone到本地后,会放到一个名为Specs的文件夹中。podspec文件在Specs仓库中的保存原则是: Pods依赖库同名文件夹--->版本号同名文件夹--->podspec文件 照此原则,我需要在Specs文件夹下建立一个名为WZMarqueeView的文件夹,然后进入到WZMarqueeView文件夹下,建立一个名称为1.0.0的文件夹,最后进入到1.0.0这个文件夹下,并且将之前创建好的WZMarqueeView.podspec文件拷贝进来。 不难理解,如果以后有对WZMarqueeView类的升级,就在WZMarqueeView文件夹下建立对应版本名称的文件夹,用于保存对应版本的podspec文件即可。 这些操作完成后,目录层次结构如下所示: \

    4、上传本地Specs仓库中的修改到github仓库

    执行以下命令:
    1.$ git add -A && git commit -m "Add WZMarqueeView podspec file"
    2.$ git push origin master
    成功以后就能在github上自己fork的Specs仓库中看到刚上传的文件了。

    5、将在自己fork的Specs上做的修改pull给CocoaPods官方的Specs仓库

    进入到自己fork的Specs仓库中,会看到屏幕左上角有一个绿色按钮: \
    该按钮点进去以后会有如下图所示的界面: \
    点击图中的绿色Create Pull Request按钮,即可将我们fork的Specs上做的修改pull给CocoaPods官方的Specs仓库。
    到这一步后,剩下的工作就只有等了,等待CocoaPods的维护人员审核并将我们pull上去的修改合并到官方的Specs仓库中,这个过程通常会有一天左右的等待时间。如果有任何消息,比如审核不通过,或者审核通过了,CocoaPods官方都会发邮件通知的。 等到审核通过的时候,我们就能在官方的Specs仓库中看到自己上传的文件夹了。

    6、查看审核进度

    当然我们也能查看审核进度,打开这个链接:https://github.com/CocoaPods/Specs/pulls,这里能看到所有的Specs仓库pull请求,如下图: \
    红圈标识的就是我刚才pull上来的请求,点进去以后就能看到对应的审核进度。

    六、查看我们自己创建的Pods依赖库

    如果收到了CocoaPods官方发过来的审核通过邮件以后,你可能很着急的想在自己的电脑上执行pod search命令,看看能不能搜索到自己创建的Pods依赖库。不过你肯定会失望的,因为还需要执行一条命令才能在我们的本地电脑上使用search命令搜索到我们的依赖库:
    1.$ pod setup
    在我的CocoaPods系列教程中的第一篇:CocoaPods详解之----进阶篇中的最后部分介绍过这条命令,它会将所有的Pods依赖库tree跟新到本地。执行完这条命令,再去执行:
    1.$ pod search WZMarqueeView
    展开全文
  • Pod基本概念

    2020-02-20 22:59:04
    pod 是k8s中最小的编排单位,从API的角度看,容器(Container)就是pod属性里的一个普通字段,那么那些属性是属于pod,哪些属性又是属于container呢? 凡是调度、网络、存储以及安全相关的属性,基本是属于pod的属性...

    文章目录


    声明 该系列文章属于极客时间专栏 ”深入剖析Kubernetes“学习笔记

    pod 是k8s中最小的编排单位,从API的角度看,容器(Container)就是pod属性里的一个普通字段,那么那些属性是属于pod,哪些属性又是属于container呢?

    凡是调度、网络、存储以及安全相关的属性,基本是属于pod的属性。
    接下来我们需要了解一些pod中重要的字段。

    ** NodeSelector** :将Pod和Node进行绑定,用法如下:

    apiVersion: v1
    kind: Pod
    ...
    spec:
     nodeSelector:
       disktype: ssd
    

    这意味着这个pod只能运行在带有”disktype:ssd“标签的节点上,否则会调度失败。

    NodeName:一旦pod的这个字段被赋值,k8s会认为这个pod已经被调度了,调度的结果就是赋予节点名字。这个字段一般有调度器负责,用户可以设置他来骗过调度器。

    HostAliases:定义Pod的hosts文件(比如/etc/hosts)里的内容,用法如下:

    apiVersion: v1
    kind: Pod
    ...
    spec:
      hostAliases:
      - ip: "10.1.2.3"
        hostnames:
        - "foo.remote"
        - "bar.remote"
    ...
    

    pod启动后,/etc/hosts文件的内容如下:

    cat /etc/hosts
    # Kubernetes-managed hosts file.
    127.0.0.1 localhost
    ...
    10.244.135.10 hostaliases-pod
    10.1.2.3 foo.remote
    10.1.2.3 bar.remote
    

    最下面两行就是通过HostAliases字段设置的。在k8s中设置hosts文件内容一般通过这种方法,如果直接修改hosts文件,当pod被删除重建之后,kubelet会自动覆盖被修改的内容。

    凡是跟容器的Linux NameSpace相关的属性,也一定是Pod级别的

    举个例子,在pod的YAML文件中设置shareProcessNameSpace=true:

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
    spec:
      shareProcessNamespace: true
      containers:
      - name: nginx
        image: nginx
      - name: shell
        image: busybox
        stdin: true
        tty: true
    

    这意味这这个Pod里的容器共享PID NameSpace也就是说整个Pod里的每个容器进程,对所有容器都是可见的,他们共享同一个PID NameSpace。

    Pod中最重要的字段是Containers。Kubernetes 项目中对 Container 的定义,和 Docker 相比并没有什么太大区别。Image(镜像)、Command(启动命令)、workingDir(容器的工作目录)、Ports(容器要开发的端口),以及 volumeMounts(容器要挂载的 Volume)都是构成 Kubernetes 项目中 Container 的主要字段。除了这些字段外,还需要关注一些额外的字段。

    ImagePullPolicy定义了镜像拉去的策略。默认为Always,即每次创建Pod都需要重新拉取一次镜像。当容器镜像的名字类似于nginx或者nginx:latest时,该字段会被认为是Always。如果他的值被定义为Never或者IfNotPresent,Pod不会主动拉去镜像,或者只在宿主机上不存在这个镜像时才拉取。

    Lifecycle他定义的时Container Lifecycle Hooks,意思是在容器状态发生变化时出发一系列”钩子“。

    apiVersion: v1
    kind: Pod
    metadata:
      name: lifecycle-demo
    spec:
      containers:
      - name: lifecycle-demo-container
        image: nginx
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
          preStop:
            exec:
              command: ["/usr/sbin/nginx","-s","quit"]
    

    在YAML文件的containers部分设置了一个postStart和preStop参数。先说postStart,它值的是容器启动之后执行一个指定的操作。preStop发生的时机是在容器被杀死之前,(比如,收到SIGKILL信号)。他会阻塞当前容器杀死流程,直到这个Hook定义的操作完成之后,才允许容器被杀死。

    Pod对象在Kubernetes中的生命周期,主要体现在Pod API对象的Status部分,这是除了Metadata和Spec之外的第三个重要字段。其中,pod.status.phase,就是 Pod 的当前状态,它有如下几种可能的情况:

    1. Pending。这个状态意味着,Pod 的 YAML 文件已经提交给了 Kubernetes,API 对象已经被创建并保存在 Etcd 当中。但是,这个 Pod 里有些容器因为某种原因而不能被顺利创建。比如,调度不成功。
    2. Running。这个状态下,Pod 已经调度成功,跟一个具体的节点绑定。它包含的容器都已经创建成功,并且至少有一个正在运行中。
    3. Succeeded。这个状态意味着,Pod 里的所有容器都正常运行完毕,并且已经退出了。这种情况在运行一次性任务时最为常见。
    4. Failed。这个状态下,Pod 里至少有一个容器以不正常的状态(非 0 的返回码)退出。这个状态的出现,意味着你得想办法 Debug 这个容器的应用,比如查看 Pod 的 Events 和日志。
    5. Unknown。这是一个异常状态,意味着 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver,这很有可能是主从节点(Master 和 Kubelet)间的通信出现了问题。
    展开全文
  • title: pod_lib_create date: 2018-04-26 tag: - CocoaTouchStaticLibrary - CocoaPods site: https://zhangkn.github.io catalog: true author: kunnan subtitle: 采用 pod lib 开发并打包静态库,比我之前...

    layout: post
    title: pod_lib_create
    date: 2018-04-26
    tag:
    - CocoaTouchStaticLibrary
    - CocoaPods
    site: https://zhangkn.github.io


    前言

    • iOS CocoaPods私有库
    • 采用 pod lib 开发并打包iOS静态库

    背景

    之前我自己搭建了一个模板,采用git_subtree进行管理;最近我喜欢上了使用cocoaPods开发打包静态库.

    开发一个用git_subtree管理依赖关系的静态类库给其他人使用,打包成.a文件。
    
    • 今天的重点就是换成 pod lib 创建开发静态类库的工程模版,并利用pod package进行打包;
    当然如果你想开源,
    1) 使用:pod lib lint验证格式
    pod lib lint KNPodlib.podspec --verbose --allow-warnings
    2) 利用pod trunk push 进行发布
    pod trunk push  KNPodlib.podspec --verbose --allow-warnings
    
    • pwd
    /Users/devzkn/code/cocoapodDemo/cocoapodStatic
    

    I、iOS CocoaPods私有库

    如果以后项目想要组建化,可以采用iOS CocoaPods私有库的方式实现

    在这里插入图片描述

    1.1 具体步骤

    • 创建私有 Git 远程仓库(用于存储代码 );

    • 创建私有 CocoaPods 远程索引库(用于保存代码的版本信息 类似CocoaPods的索引库 );

    pod repo add CocoaPodsIndex https://github.com/CocoaPodsIndex/CocoaPodsIndex.git
    
    
    • 创建 Pod 所需要的项目工程文件,并上传到 Git 远程私有库;

    • 验证 podspec 描述文件;

    • 向私有 CocoaPods 远程索引库提交 podspec 描述文件;

    • 使用 Pod 库;

    1.2 podspec描述文件的关键配置参数

    • KNGotoSafari.podspec
      s.source_files = 'KNGotoSafari/Classes/**/*'
      #使用了 s.resource_bundles,之后,会自动创建KNPodlib.bundle
    
       s.resource_bundles = {
         'KNGotoSafari' => ['KNGotoSafari/Assets/*.png']
       }
    
       s.public_header_files = 'Pod/Classes/**/*.h'
      # s.frameworks = 'UIKit', 'MapKit'
      #如果有多个第三方依赖:  有多个第三方库,就写多个 s.dependency
      
       s.dependency 'ReactiveObjC'
       s.dependency 'Masonry', '~> 1.1.0'
    
    

    II、 CocoaTouchStaticLibrary

    2.1 使用Xcode模版开发静态库

    Xcode->Cocoa Touch Static Library
    [可选]:创建Podfile文件、执行pod install完成整个项目的搭建
    [可选]:demo使用pod添加对私有静态库的依赖
    

    2.2 、使用 pod lib create 生成一个本地私有库

    • 例子参考KNPodlib

    只需要输入 pod 的 lib 命令即可完成初始项目的搭建

    • Commands:
      + create    Creates a new Pod
       + lint      Validates a Pod
    

    2.3 打包静态库的命令预览:

    • pod lib create
    ➜  lib pod lib create KNGotoSafari
    
    
    https://kunnan.blog.csdn.net/article/details/103830544
    ➜  lib pod lib create KNGotoSafari
    
    Running pod install on your new library.
    
    Analyzing dependencies
    Fetching podspec for `KNGotoSafari` from `../`
    Downloading dependencies
    Installing KNGotoSafari (0.1.0)
    Generating Pods project
    Integrating client project
    
    [!] Please close any current Xcode sessions and use `KNGotoSafari.xcworkspace` for this project from now on.
    Sending stats
    Pod installation complete! There is 1 dependency from the Podfile and 1 total pod installed.
    
     Ace! you're ready to go!
     We will start you off by opening your project in Xcode
      open 'KNGotoSafari/Example/KNGotoSafari.xcworkspace'
    
    To learn more about the template see `https://github.com/CocoaPods/pod-template.git`.
    To learn more about creating a new pod, see `https://guides.cocoapods.org/making/making-a-cocoapod`.
    
    
    • pod install
    ➜  Example git:(master) ✗ pod install
    Analyzing dependencies
    Fetching podspec for `KNGotoSafari` from `../`
    Downloading dependencies
    Installing KNGotoSafari 0.1.0
    Installing Masonry (1.1.0)
    Installing ReactiveObjC (3.1.1)
    Generating Pods project
    Integrating client project
    Sending stats
    Pod installation complete! There is 1 dependency from the Podfile and 3 total pods installed.
    
    
    • 打包。此时你需要安装一个 CocoaPods 打包插件pod packagepod package KNGotoSafari.podspec --library --force
    `➜  KNGotoSafari git:(master) ✗ pod package KNGotoSafari.podspec  --library   --force
    
    

    2.4、 Using Pod Lib Create 具体的使用步骤

    • Getting started
    pod lib create KNPodlib
    1) Note: To use your own pod-template you can add the parameter --template-url=URL where URL is the git repo containing a compatible template.
    2)Second Note: you can press return to select the default (underlined) option.
    
    • Objective-C or Swift
    For both choices CocoaPods will set up your library as a framework.
    
    • Making a Demo Application
    This means you don't have to go through creating a new project in Xcode.
    If you want to have an example project for pod try MyLib or need to have your library's tests run inside an application ( interaction tests, custom fonts, etc ) then you should say yes.
    A good metric is "Should this Pod include a screenshot?"; if so, then you should have a demo.
    
    • Choosing a Test Framework
    1) in Objective-C we include a choice of two popular testing frameworks; Specta/Expecta and Kiwi. If you can't decide, use Specta/Expecta.
    We include all the necessary includes and setup for your testing framework in MyLib-Tests.pch so that you don't have to include them in each file.
    2) In Swift we only offer the choice of Quick/Nimble as this looks to be the dominant testing library.
    
    A light-weight TDD / BDD framework for Objective-C & Cocoa.
    
    a Behaviour Driven Development library for iOS development. The goal is to provide a BDD library that is exquisitely simple to setup and use.
    
    • View-based Testing
    We recommend using FBSnapShotTestCase, if you are using Specta/Expecta then we include a Pod to improve the syntax.
    
    • Prefixes for Objective-C
    We know that Apple is deprecating prefixes, but in reality they still have their place in Objective-C codebases.
    

    2. 5、The Pod Lib Create Template

    • The Pod Lib Create Template :tree -L 2
    run pod install on the newly created Project
    .
    ├── Example
    │   ├── KNPodlib
    │   ├── KNPodlib.xcodeproj
    │   ├── KNPodlib.xcworkspace
    │   ├── Podfile
    │   ├── Podfile.lock
    │   ├── Pods
    │   └── Tests
    ├── KNPodlib
    │   ├── Assets
    │   └── Classes
    ├── KNPodlib.podspec
    ├── LICENSE
    ├── README.md
    └── _Pods.xcodeproj -> Example/Pods/Pods.xcodeproj
    10 directories, 5 files
    

    进入Example文件夹, 执行 pod install, 让项目安装依赖并配置更新

    在 /Classes 文件中添加需要的代码:(对应于XCLogStaticDemo.podspec 的 source_files 目录)

    III、实践

    3.0、pod lib create KNPodlib

    • pod lib create KNPodlib
    Cloning `https://github.com/CocoaPods/pod-template.git` into `KNPodlib`.
    Configuring KNPodlib template.
    To learn more about the template see `https://github.com/CocoaPods/pod-template.git`.
    To learn more about creating a new pod, see `http://guides.cocoapods.org/making/making-a-cocoapod`.
    
    • To get you started we need to ask a few questions, this should only take a minute.
    The domain/default pair of (org.cocoapods.pod-template, HasRunbefore) does not exist
    If this is your first time we recommend running through with the guide: 
    
    • https://guides.cocoapods.org/making/using-pod-lib-create.html
      ( hold cmd and double click links to open in a browser. )
    *  ask a few questions
    
    

    What platform do you want to use?? [ iOS / macOS ]
    ios
    What language do you want to use?? [ Swift / ObjC ]
    ObjC
    Would you like to include a demo application with your library? [ Yes / No ]
    yes
    Which testing frameworks will you use? [ Specta / Kiwi / None ]
    Specta
    Would you like to do view based testing? [ Yes / No ]
    Yes
    What is your class prefix?
    KN
    Running pod install on your new library.
    Analyzing dependencies
    Fetching podspec for KNPodlib from ../
    Downloading dependencies
    To learn more about creating a new pod, see http://guides.cocoapods.org/making/making-a-cocoapod.

    
    

    3.1、The Pod Lib Create Template

    • tree -L 3
    .
    ├── Example # This is the generated Demo & Testing bundle
    │   ├── KNPodlib
    │   │   ├── Base.lproj
    │   │   ├── Images.xcassets
    │   │   ├── KNAppDelegate.h
    │   │   ├── KNAppDelegate.m
    │   │   ├── KNPodlib-Info.plist
    │   │   ├── KNPodlib-Prefix.pch
    │   │   ├── KNViewController.h
    │   │   ├── KNViewController.m
    │   │   ├── en.lproj
    │   │   └── main.m
    │   ├── KNPodlib.xcodeproj
    │   │   ├── project.pbxproj
    │   │   ├── project.xcworkspace
    │   │   └── xcshareddata
    │   ├── KNPodlib.xcworkspace
    │   │   ├── contents.xcworkspacedata
    │   │   └── xcuserdata
    │   ├── Podfile
    │   ├── Podfile.lock
    │   ├── Pods
    │   │   ├── Expecta
    │   │   ├── Expecta+Snapshots
    │   │   ├── FBSnapshotTestCase
    │   │   ├── Headers
    │   │   ├── Local\ Podspecs
    │   │   ├── Manifest.lock
    │   │   ├── Pods.xcodeproj
    │   │   ├── Specta
    │   │   └── Target\ Support\ Files
    │   └── Tests
    │       ├── Tests-Info.plist
    │       ├── Tests-Prefix.pch
    │       ├── Tests.m
    │       └── en.lproj
    ├── KNPodlib #This is where you place your library's classes
    │   ├── Assets
    │   └── Classes
    │       └── ReplaceMe.m # a single file to to ensure compilation works initially
    ├── KNPodlib.podspec
    ├── LICENSE #defaulting to the MIT License.
    ├── README.md
    ├── .travis.yml #a setup file for travis-ci.
    └── _Pods.xcodeproj -> Example/Pods/Pods.xcodeproj #a symlink to your Pod's project for Carthage support
    
    
    • /Users/devzkn/code/cocoapodDemo/cocoapodStatic/KNPodlib/Example/Pods/Target Support Files/KNPodlib
    # references:
    
    
    • https://www.objc.io/issues/6-build-tools/travis-ci/

    • https://github.com/supermarin/xcpretty#usage

    osx_image: xcode7.3
    language: objective-c

    cache: cocoapods

    podfile: Example/Podfile

    before_install:

    • gem install cocoapods # Since Travis is not always on latest version

    • pod install --project-directory=Example

    script:

    • set -o pipefail && xcodebuild test -enableCodeCoverage YES -workspace Example/KNPodlib.xcworkspace -scheme KNPodlib-Example -sdk iphonesimulator9.3 ONLY_ACTIVE_ARCH=NO | xcpretty
    • pod lib lint
    
    

    3.3、Putting your Library Together

    • cat .gitignore
    • edit your Podspec metadata
    change your README and Podspec.
    
    
    • Development Pods
    1) Development Pods are different from normal CocoaPods in that they are symlinked files,so you can work on your library from inside Xcode.
    2)  Your demo & tests will need to include references to headers using the #import <MyLib/XYZ.h> format.
    
    
    • [!] Note:运行Pod install,让demo程序加载新建的类
    Due to a Development Pods implementation detail, when you add new/existing files to Pod/Classes or Pod/Assets or update your podspec, you should run pod install or pod update
    只要新增加类/资源文件或依赖的三方库都需要重新运行Pod install来应用更新
    
    
    • cd Example ;执行pod install,让demo项目安装依赖项并更新配置
    pod install --no-repo-update
    devzkndeMacBook-Pro:Example devzkn$ pod install --no-repo-update
    Analyzing dependencies
    Fetching podspec for `KNPodlib` from `../`
    Sending stats
    See `https://guides.cocoapods.org/syntax/podfile.html#platform`.
    
    
    • 使用了 s.resource_bundles,之后,会自动创建KNPodlib.bundle
    devzkndeMacBook-Pro:KNPodlib devzkn$ tree -L 2
    .
    ├── KNPodlib.bundle
    │   ├── HCPCMPayProgress.nib
    │   ├── Info.plist
    │   ├── KNFeedbackViewController.nib
    │   ├── deleteX.png
    │   ├── hebaoGrayPoint.png
    │   ├── hebaoWhitePoint.png
    │   └── store_add.png
    └── KNPodlib.framework
     ├── Headers
     ├── Info.plist
     ├── KNPodlib
     ├── Modules
     └── _CodeSignature
    
    

    IV开发细节

    4.1、 public_header_files 配置

    • s.public_header_files
     s.public_header_files = 'Classes/PublicInterface/*.h'
    
      KNPodlib/KNPodlib-umbrella.h
    
    #ifdef __OBJC__
    
    #import <UIKit/UIKit.h>
    
    #else
    
    #ifndef FOUNDATION_EXPORT
    
    #if defined(__cplusplus)
    
    #define FOUNDATION_EXPORT extern "C"
    
    #else
    
    #define FOUNDATION_EXPORT extern
    
    #endif
    
    #endif
    
    #endif
    
    #import "HCPEnvrionmentalVariables.h"
    
    #import "KNFeedbackViewController.h"
    
    #import "KNTestWebViewController.h"
    
    FOUNDATION_EXPORT double KNPodlibVersionNumber;
    FOUNDATION_EXPORT const unsigned char KNPodlibVersionString[];
    
    

    4.2、提交本地代码库

    • devzkndeMacBook-Pro:KNPodlib devzkn$ kngitinit git@github.com:zhangkn/KNPodlib.git

    • 提交源码,并打tag。

    git add .
    git commit -a -m 'v0.1.0'
    git tag -a 0.1.0 -m 'v0.1.0'
    
    

    #git tag -a v1.0 -m ‘xxx’

    git push origin --tags
    To github.com:zhangkn/KNPodlib.git

    • [new tag] 0.1.0 -> 0.1.0
    • [new tag] 0.1.1 -> 0.1.1
    #  Deploying your Library
    
    

    4.3、验证类库

    • First you should check if the Podspec lints correctly
    pod lib lint and pod spec lint
    1)The difference between them is that 
    2) pod lib lint does not access the network, whereas pod spec lint checks the external repo and associated tag.
    
    
    • devzkndeMacBook-Pro:KNPodlib devzkn$ pod lib lint KNPodlib.podspec --verbose --allow-warnings
    KNPodlib passed validation.
    
    

    V、打包类库(只有完成这一个步骤,才达到静态库的目的,否则就是开源的了)

    • 没有执行打包类库这个步骤,直接deploy to the public的效果
    ├── Podfile
    ├── Podfile.lock
    ├── Pods
    │   ├── Headers
    │   ├── KNPodlib
    │   │   ├── Assets
    │   │   │   ├── deleteX.png
    │   │   │   ├── hebaoGrayPoint.png
    │   │   │   ├── hebaoWhitePoint.png
    │   │   │   └── store_add.png
    │   │   ├── Classes
    │   │   │   ├── PublicInterface
    │   │   │   │   ├── HCPEnvrionmentalVariables.h
    │   │   │   │   ├── KNBaseViewController.h
    │   │   │   │   ├── KNBaseWebViewController.h
    │   │   │   │   ├── KNFeedbackViewController.h
    │   │   │   │   └── KNTestWebViewController.h
    │   │   │   ├── ReplaceMe.m
    │   │   │   └── main
    │   │   │       ├── knFeedback
    │   │   │       │   ├── model
    │   │   │       │   ├── vc
    │   │   │       │   └── view
    │   │   │       ├── tool
    │   │   │       │   ├── HCPEnvrionmentalVariables.m
    │   │   │       │   ├── HSSingleton.h
    │   │   │       │   ├── IPLoadingTool.h
    │   │   │       │   ├── IPLoadingTool.m
    │   │   │       │   ├── KNResourceTool.h
    │   │   │       │   ├── KNResourceTool.m
    │   │   │       │   ├── const
    │   │   │       │   └── view
    │   │   │       └── webview
    │   │   │           ├── BaseWebView
    │   │   │           ├── javaScriptContext
    │   │   │           └── progress
    │   │   ├── LICENSE
    │   │   └── README.md
    
    
    • 执行pod package KNPodlib.podspec --force 之后的效果

    • 执行pod package KNPodlib.podspec --force 之前的准备

    devzkndeMacBook-Pro:KNPodlib devzkn$ git tag -a 0.1.8 -m "0.1.8"
    git push origin --tags
    pod package KNPodlib.podspec --force
    tree -L 4
    ── KNPodlib-0.1.9
    │   ├── KNPodlib.podspec
    │   ├── build
    │   │   └── Pods.build
    │   │       ├── Release-iphoneos
    │   │       └── Release-iphonesimulator
    │   └── ios
    │       └── KNPodlib.framework
    │           ├── Headers -> Versions/Current/Headers
    │           ├── KNPodlib -> Versions/Current/KNPodlib
    │           ├── Resources -> Versions/Current/Resources
    │           └── Versions
    pod lib lint KNPodlib.podspec --verbose --allow-warnings
    pod trunk push  KNPodlib.podspec --verbose --allow-warnings
    
    

    5.1 deploy to the public

    pod trunk push [NAME.podspec] will deploy your Podspec to Trunk and make it publicly available. You can also deploy Podspecs to your own private specs repo with pod repo push REPO [NAME.podspec].

    • Deploying a library
    If you're deploying an Open Source library to trunk, you cannot have CocoaPods warnings. You can have Xcode warnings though. You should continue to the getting started with trunk guide to deploy to the public.
    pod repo push SPEC_REPO *.podspec --verbose
    
    

    5.1.1、deploy Podspecs to your own private specs repo

    pod repo push REPO [NAME.podspec].

    1) Lints your Podspec locally. You can lint at any time with  pod spec lint [NAME.podspec]
    2) A successful lint pushes your Podspec to Trunk or your private specs repo
    3) Trunk will publish a canonical JSON representation of your Podspec
    
    
    • pod repo push SPEC_REPO *.podspec --verbose
    If you're deploying to a private Specs repo, you will need to have already added that repo.  use this command to deploy:
    pod repo push SPEC_REPO *.podspec --verbose
    
    

    5.1.2、 deploy your Podspec to Trunk and make it publicly available

    • pod trunk push [NAME.podspec] —allow-warnings
    pod trunk push —allow-warnings 
    
    
    • devzkndeMacBook-Pro:KNPodlib devzkn$ pod trunk push KNPodlib.podspec --verbose --allow-warnings
    Updating spec repo `master`
    CocoaPods 1.5.0 is available.
      - April 26th, 20:21: Push for `KNPodlib 0.1.3' has been pushed (0.801533271 s).
    
    
    devzkndeMacBook-Pro:KNPodlib devzkn$ pod trunk info KNPodlib
    KNPodlib
     - Versions:
       - 0.1.3 (2018-04-27 02:21:06 UTC)
     - Owners:
       - zhangkn <developerkunnan@gmail.com>
    
    
    • 注意事项
    1) 以后再次更新只需要把你的项目打一个tag,然后修改.podspec文件中的版本,接着提交到cocoapods官方.
    2) 手动验证 Pod 时使用了 --use-libraries(引用了.a文件的时候需要使用) 或 --allow-warnings 等修饰符,那么发布的时候也应该使用相同的字段修饰,否则出现相同的报错
    
    

    5.1.3、Adding other people as contributors

    The first person to push a Podspec version to Trunk can add other maintainers.

    • For example, to add kyle@cocoapods.org to the library ARAnalytics:
    $ pod trunk add-owner ARAnalytics kyle@cocoapods.org
    
    

    5.1.4、Claiming an existing library

    you can use our Claims form to say that you are the owner or maintainer of a collection of libraries

    OWNER NAME:
    OWNER EMAIL:
    CLAIM POD:
    
    

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uDxMqDv9-1578105112068)(https://ws2.sinaimg.cn/large/006tNc79gy1fqr1s3u069j31kw0jttan.jpg)]

    • Note you can usepod trunk info [pod]to get information on a pod and pod trunk mecan be used to verify your local account.

    • KNPodlib claims

    VI、关于 Pod 库的资源引用 resource_bundles or resources

    We strongly recommend library developers to adopt resource bundles as there can be name collisions using the resources attribute. Moreover, resources specified with this attribute are copied directly to the client target and therefore they are not optimised by Xcode.

    6.1 resource_bundles

    CocoaPods 官方强烈推荐使用 resource_bundles,因为用 key-value 可以避免相同名称资源的名称冲突。

    • 存放的位置: 隔离了各个库或者一个库下的资源包
    devzkndeMacBook-Pro:KNPodlib_Example.app devzkn$ tree -L 4
    .
    ├── Base.lproj
    │   └── LaunchScreen.storyboardc
    │       ├── 01J-lp-oVM-view-Ze5-6b-2t3.nib
    │       ├── Info.plist
    │       └── UIViewController-01J-lp-oVM.nib
    ├── Frameworks
    │   └── KNPodlib.framework
    │       ├── HCPCMPayProgress.nib
    │       ├── Info.plist
    │       ├── KNFeedbackViewController.nib
    │       ├── KNPodlib
    │       ├── KNPodlib.bundle
    │       │   ├── Info.plist
    │       │   ├── deleteX.png
    │       │   ├── hebaoGrayPoint.png
    │       │   ├── hebaoWhitePoint.png
    │       │   └── store_add.png
    │       └── _CodeSignature
    │           └── CodeResources
    
    

    6.2 resources

    使用 resources 来指定资源,被指定的资源只会简单的被 copy 到目标工程中(主工程)。

    • resources
    spec.ios.resource_bundle = { 'MapBox' => 'MapView/Map/Resources/*.png' }
    
    
    >* Examples
    >
    >```
    >spec.resource = 'Resources/HockeySDK.bundle'
    >spec.resources = ['Images/*.png', 'Sounds/*']
    >```
    
    >* [syntax - podspec](https://guides.cocoapods.org/syntax/podspec.html)
    >
    >
    >* 读取图片的方式和平常使用的方式不同,要先获取 Bundle;可以使用相对方式获取
    >```
    >UIImage *image = [UIImage imageNamed:@"some-image"
                                    inBundle:[NSBundle bundleForClass:[self class]]
               compatibleWithTraitCollection:nil];
    >```
    

    6.3 对于 Pods 库的资源,同样可以使用 .xcassets 管理。

    resources 和 resource_bundles 都可以很好的支持 .xcassets 的引用

    6.4、小结

    >* resource_bundles 优点:
    >```
    >可以使用 .xcassets 指定资源文件
    可以避免每个库和主工程之间的同名资源冲突
    >```
    >
    >* resource_bundles 缺点:我觉得还好
    >```
    >获取图片时可能需要使用硬编码的形式来获取:[[NSBundle bundleForClass:[self class]].resourcePath stringByAppendingPathComponent:@"/SubModule_Use_Bundle.bundle"]
    >```
    >
    >* resources 优点:
    >
    >```
    >可以使用 .xcassets 指定资源文件
    >```
    >
    >* resources 缺点:
    >```
    >会导致每个库和主工程之间的同名资源冲突
    不需要用硬编码方式获取图片:[NSBundle bundleForClass:[self class]] compatibleWithTraitCollection:nil];
    >```
    >
    >
    

    VI、Demo

    >* [KNPodlibDemo](https://github.com/kunnan/KNPodlibDemo)
    >
    >
    >* 修改podfile之后,只有执行pod  install之后才能生效
    
    
    

    知识补充:pod package

    7.1 s.source

    • s.source 为本地的时候记得写绝对路径

    前面提到过使用pod package打包时候需要注意.pod会根据当前podspec中的s.source的地址去查找当前sdk源文件的地址.如果使用的s.source = { :git => ‘https://github.com/brownfeng/MyCustomLib.git’, :tag => s.version.to_s },那么就会去git中拉取最后一个tag对应commit的源码.如果使用的s.source = { :git => ‘/Users/pp/Desktop/MyCustomLib’},那么会使用当前sdk中git 的HEAD位置的commit的源码进行打包编译.(如果源码有修改,一定要先git commit,然后再打包)

    7.2 pod package

    ➜ KNGotoSafari git:(master) ✗ pod package KNGotoSafari.podspec --library --force
    注意了,如果命令后面加条尾巴 --library 则表示打包成 .a 文件,如果不带,则会打包成 .framework 文件。而 --force 则表示强制覆盖之前存在的文件

    • Package a podspec into a static library.

    使用一个cocoapods的插件cocoapods-packager来完成类库的打包.

    
    >* 安装打包插件:gem install cocoapods-packager
    >
    >```
    >sudo gem install cocoapods-packager
    >Done installing documentation for concurrent-ruby, i18n, thread_safe, tzinfo, activesupport, nap, fuzzy_match, cocoapods-core, claide, cocoapods-deintegrate, cocoapods-downloader, cocoapods-plugins, cocoapods-search, cocoapods-stats, netrc, cocoapods-trunk, cocoapods-try, molinillo, atomos, CFPropertyList, colored2, nanaimo, xcodeproj, escape, fourflusher, gh_inspector, ruby-macho, cocoapods, cocoapods-packager after 20 seconds
    >29 gems installed
    >
    >```
    
    
    >* pod package --help
    >
    >```
    >   $ pod package NAME [SOURCE]
    >
    >```
    
    >* Options:
    >
    ><script src="https://gist.github.com/zhangkn/62bcfd228864db619a99fe7363002b59.js"></script>
    >
    >*  pod package KNPodlib.podspec --force
    >
    >```
    >Building framework KNPodlib (0.1.5) with configuration Release
    >Mangling symbols
    >Building mangled framework
    >// 这个时候如果报错:Unable to run command 'StripNIB,因为source_files包含了xib.
    >├── KNPodlib-0.1.5
    >│   ├── KNPodlib.podspec
    >│   ├── build
    >│   │   └── Pods.build
    >│   │       ├── Release-iphoneos
    >│   │       │   ├── KNPodlib-KNPodlib.build
    >│   │       │   ├── KNPodlib.build
    >│   │       │   └── Pods-packager.build
    >│   │       └── Release-iphonesimulator
    >│   │           ├── KNPodlib-KNPodlib.build
    >│   │           ├── KNPodlib.build
    >│   │           └── Pods-packager.build
    >│   └── ios
    >│       └── KNPodlib.framework
    >│           ├── Headers -> Versions/Current/Headers
    >│           ├── KNPodlib -> Versions/Current/KNPodlib
    >│           ├── Resources -> Versions/Current/Resources
    >│           └── Versions
    >│               ├── A
    >│               └── Current -> A
    >
    

    VIII 、Q&A

    8.1、Unable to run command ‘StripNIB KNFeedbackViewController~ipad.nib’ - this target might include its own product.

    • s.source_files = ‘Classes/**/*’
    xib不能当成源文件(即s.source_files),否则 pod package KNPodlib.podspec --force 会报以上错误。
    应当修改为:
    s.source_files = 'Classes/**/*.{h,m}'
    
    
    • Cocoapod compilation fails when loading .xib file
    s.resource = "Project/**/*.{png,bundle,xib,nib}"
    
    
    • resource_bundles
     "resource_bundles": {
      "KNPodlib": [
    -      "Assets/*.png"
    +      "Assets/*.png",
    +      "Classes/**/*.xib"
      ]
    },
    
    
    • 增加"Classes/**/*.xib" 之后, KNPodlib.bundle的资源文件情况的变化
      ├── KNPodlib.bundle
     │   ├── Info.plist
     │   ├── deleteX.png
     │   ├── hebaoGrayPoint.png
     │   ├── hebaoWhitePoint.png
     │   └── store_add.png
     <!--增加之后的情况-->
         ├── KNPodlib.bundle
     │   ├── HCPCMPayProgress.nib
     │   ├── Info.plist
     │   ├── KNFeedbackViewController.nib
     │   ├── deleteX.png
     │   ├── hebaoGrayPoint.png
     │   ├── hebaoWhitePoint.png
     │   └── store_add.png
    
    

    8.2:cannot load such file – xcodeproj (LoadError)

    • pod lib create KNPodlib
    devzkndeMacBook-Pro:cocoapodStatic devzkn$ pod lib create KNPodlib
    Cloning `https://github.com/CocoaPods/pod-template.git` into `KNPodlib`.
    Configuring KNPodlib template.
    Traceback (most recent call last):
    6: from ./configure:4:in `<main>'
    5: from ./configure:4:in `each'
    4: from ./configure:5:in `block in <main>'
    3: from ./configure:5:in `require_relative'
    2: from /Users/devzkn/code/cocoapodDemo/cocoapodStatic/KNPodlib/setup/ProjectManipulator.rb:1:in `<top (required)>'
    1: from /usr/local/Cellar/ruby/2.5.1/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
    /usr/local/Cellar/ruby/2.5.1/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot load such file -- xcodeproj (LoadError)
    To learn more about the template see `https://github.com/CocoaPods/pod-template.git`.
    To learn more about creating a new pod, see `http://guides.cocoapods.org/making/making-a-cocoapod`.
    
    
    • ruby -v、pod --version
    devzkndeMacBook-Pro:rubygems devzkn$ ruby -v   
    ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17]
    devzkndeMacBook-Pro:rubygems devzkn$ pod  --version
    1.4.0
    
    
    • A1:gem install xcodeproj
    Fetching: atomos-0.1.2.gem (100%)
    Successfully installed atomos-0.1.2
    Fetching: CFPropertyList-3.0.0.gem (100%)
    Successfully installed CFPropertyList-3.0.0
    Fetching: claide-1.0.2.gem (100%)
    Successfully installed claide-1.0.2
    Fetching: colored2-3.1.2.gem (100%)
    Successfully installed colored2-3.1.2
    Fetching: nanaimo-0.2.5.gem (100%)
    Successfully installed nanaimo-0.2.5
    Fetching: xcodeproj-1.5.7.gem (100%)
    Successfully installed xcodeproj-1.5.7
    Parsing documentation for atomos-0.1.2
    Installing ri documentation for atomos-0.1.2
    Parsing documentation for CFPropertyList-3.0.0
    Installing ri documentation for CFPropertyList-3.0.0
    Parsing documentation for claide-1.0.2
    Installing ri documentation for claide-1.0.2
    Parsing documentation for colored2-3.1.2
    Installing ri documentation for colored2-3.1.2
    Parsing documentation for nanaimo-0.2.5
    Installing ri documentation for nanaimo-0.2.5
    Parsing documentation for xcodeproj-1.5.7
    Installing ri documentation for xcodeproj-1.5.7
    Done installing documentation for atomos, CFPropertyList, claide, colored2, nanaimo, xcodeproj after 3 seconds
    6 gems installed
    
    

    8.3、Unsupported Swift Version

    • Unsupported Swift Version
    The target “FBSnapshotTestCase” contains source code developed with Swift 2.x. Xcode 9 does not support building or migrating Swift 2.x targets.
    Use Xcode 8.x to migrate the code to Swift 3.
    
    
    • A: 我这里直接采用废弃FBSnapshotTestCase,从podfile删除FBSnapshotTestCase

    8.4、引用的静态库资源图片没找到

    • A:

    8.5 Authentication token is invalid or unverified. Either verify it with the email that was sent or register a new session

    ➜  ChainAttributedString git:(master) ✗ pod trunk register 929118967@qq.com kunnan
    
    

    8.6 rvm的安装

    • 安装rvm,ruby vision manager
    $curl -L get.rvm.io | bash -s stable
    $source ~/.bashrc
    $source ~/.bash_profile  
    
    
    • $rvm list known
    // 查看所有的ruby版本,如果有明确想升级的版本,可不查看
    
    
    >
    >* $rvm install 2.3.0  // 开始安装
    >
    

    VIIII 、see also

    • https://tool.lu/hexstr/
    
    /Users/devzkn/bin/knpost pod_lib_create cocoaPods开发打包静态库,比我之前自己搭建的模板更方便 -t CocoaTouchStaticLibrary
    
    > #原来""的参数,需要自己加上""
    
    
    展开全文
  • Kubernetes基本概念(三)之Pod详解

    万次阅读 2017-09-28 16:27:36
    1. Pod的定义文件apiVersion: v1 kind: Pod metadata: name: string namaspace: string labels: - name: string annotations: - name: string spec: containers: - name: string images: string i
  • Pod 在微服务中的运用

    千次阅读 2018-04-11 09:44:54
    本文主要包括 Pod 的基本概念、使用场景,以及如何在时速云平台上进行 Pod 的编排部署,希望对大家在进行微服务架构实践时有所帮助。1.我们先来看一下 Pod 的基本特性Pod 是 Kubernetes 为部署、管理、编排容器化...
  • pod的概念

    2020-11-13 00:12:43
    本文主要包括Pod的基本概念、使用场景,以及如何在时速云平台上进行Pod的编排部署,希望对大家在进行微服务架构实践时有所帮助。 1.我们先来看一下Pod的基本特性 Pod是 Kubernetes为部署、管理、编排容器化应用...
  • pod 详解

    2019-09-26 16:05:49
    静态pod是由kubelet进行管理的仅存在于特定的node上的pod. pod容器共享volume同一个pod中的多个容器能够共享pod级别的存储卷volume pod的配置管理 应用配置管理方案-configmap configmap必须在pod之前创建 在...
  • k8s专栏-pod(一)

    2020-11-15 18:51:12
    其他资源作用是支持pod,如控制器是为了管控pod,Service和Ingress是为了暴露pod引用对象,PersistentVolume为pod提供存储 pod不是容器,是一个或多个容器组成。k8s不会直接操作容器 一个pod中共享网络命名空间 ...
  • pod install vs. pod update (心得总结)

    千次阅读 2018-12-20 17:58:26
    坦白承认,用了CocoaPods快半年,今天才真正搞清楚pod install和pod update这两个命令的用法。具体的用法可以参考我在另一篇文章中翻译的官网介绍《pod install vs. pod update(原文翻译)》。这篇文章是我自己实践...
  • k8s笔记二(pod资源的创建与管理)

    千次阅读 2019-03-20 11:30:50
    Pod是kubernetes系统中的最小调度单元,也是基础单元,而其他的大多数资源对象都是用于支撑和扩展pod对象功能的。而pod的创建可以通过命令创建或者将pod资源定义为资源清单,再通过定义的清单创建。 一、通过命令...
  • 强制删除k8s的pod

    千次阅读 2019-02-19 22:57:04
    序言 好久不摸k8s,快忘记怎么玩了,离技术的距离越来越远了。 如果每天都是一个故障,每天都复盘一下,你就知道你的时间都浪费在哪儿了。强制删除pod 故事背...
  • 看完k8s文档,好多概念似乎明白了,又似乎不明白,多个概念之间的关系也很混乱,不是很明白,不要紧,接下来,好好分析一下。 结论 您有可能在急着找答案搜到我这篇文章,不费话...我的k8s集群中目前有一个pod,它...
  • 关于POD

    千次阅读 2015-12-15 14:54:58
    A plain old data structure (POD) is a data structure that is represented only as passive collections of field values, without using encapsulation or other object-oriented features. POD是...
  • 有时候我们想自己定义DNS服务器和自己添加一个DNS记录
  • Kubernetes基础:重启pod的方法

    万次阅读 2020-01-03 21:32:23
    Kubernetes没有提供诸如docker restart类似的命令用于重启容器那样重启pod的命令,一般会结合restartPolicy进行自动重启,这篇文章整理一下偶尔需要手动进行重启的时候所需要使用的方法。
  • Kubernetes基础:包含多个容器的Pod

    千次阅读 2020-02-09 18:40:51
    在前面的文章中介绍了Pod的使用方法,示例中的Pod包含一个容器,这篇文章介绍一下包含多个容器的Pod的使用方法。
  • Pod状态及生命周期

    千次阅读 2019-09-18 22:04:51
    Pod分为两类: 自主式Pod:这种Pod本身是不能自我修复的。当Pod被创建后(不论是由你直接创建还是被其它COntroller),都会被K8s调度到集群的Node上。直到pod的进程终止、被删掉。因为缺少资源而被驱逐、或者Node...
  • C++11 POD 类型

    千次阅读 2018-08-09 11:50:33
    POD(Plain Old Data,普通旧数据)类型是从C++11开始引入的概念,Plain代表它是一个普通类型,Old代表它可以与C兼容。通俗的讲,一个类、结构、共用体对象或非构造类型对象能通过二进制拷贝(如memcpy())后还能...
  • Cocoapods是非常好用的一个iOS依赖管理工具,使用它可以方便的管理和更新项目中所使用到的第三方库,以及将自己的项目中的公共组件交由它去管理。用它管理起第三方库确实是十分的...整体先说明一下创建一个私有的pod

空空如也

1 2 3 4 5 ... 20
收藏数 137,243
精华内容 54,897
关键字:

pod