pod_podman - CSDN
精华内容
参与话题
  • pod 的详细介绍及使用

    千次阅读 2016-10-25 10:26:50
    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
    展开全文
  • Kubernetes-核心资源之Pod

    千次阅读 2018-08-18 22:05:55
    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基本概念

    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)间的通信出现了问题。
    展开全文
  • pod 详解

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

    静态pod是由kubelet进行管理的仅存在于特定的node上的pod.

    pod容器共享volume同一个pod中的多个容器能够共享pod级别的存储卷volume

    pod的配置管理  应用配置管理方案-configmap

    configmap必须在pod之前创建

    在容器中获取pod信息   每个pod创建出来系统分配唯一的名字,ip地址并处于每个namespace中  要去pod的重要信息用downward api

    valuefrom  和  resourceFieldRef可以将容器的资源请求和资源限制等配置,设置为容器内部的环境变量。

     pod生命周期和重启策略

    重启策略   always:当容器失效时,由kubelet自动重启该容器

         onfailuew:当容器终止运行且退出码不为零时,由kubelet自动重启该服务

         never:不论容器运行状态如何,kubelet都不会重启该容器

    LivenessProbe探针:用于判断容器是否存活(running状态)

    ReadinessProbe探针:用于判断容器服务是否可用(ready状态)

    node亲和性调度:1.必须满足指定的规则啊才可以调度pod到node上相当于硬限制,2.强调优先满足指定规则,调度器会尝试调度pod到node上。

     

    转载于:https://www.cnblogs.com/huhuxixi/p/11460308.html

    展开全文
  • Kubernetes基本概念(三)之Pod详解

    万次阅读 2019-03-18 14:20:44
    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 为部署、管理、编排容器化...
  • K8S系列学习之Pod实战

    2020-10-13 23:28:26
    Kubernetes学习路上的那些事儿,很有必要分享出来 ...在k8s世界中,重点是把这些篮子调度和管理好,所以得首先学Pod,只有理解和掌握了Pod,后面的一些k8s组件学习起来才有意思。 实操过程 实验准备:...
  • IOS pod 使用

    千次阅读 2019-04-09 12:16:13
    背景:之前只是简单的使用flutter或自己创建一个工程简单的玩一下ios,最近打算使用一些第三方的公共库,就需要使用pod工具,在此记录下来。 1.安装cocoapods sudo gem install cocoapods 2.进入工程目录下,使用...
  • k8s笔记二(pod资源的创建与管理)

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

    2020-06-24 16:04:51
    基本步骤如下 未删除第3步的文件会有以下报错 Showing All Errors Only Unable to load contents of file list: '/Target Support Files/Pods-TimeSelectView/Pods-TimeSelectView-frameworks-Debug-input-files....
  • 强制删除k8s的pod

    千次阅读 2019-02-20 00:19:50
    序言 好久不摸k8s,快忘记怎么玩了,离技术的距离越来越远了。 如果每天都是一个故障,每天都复盘一下,你就知道你的时间都浪费在哪儿了。强制删除pod 故事背...
  • pod 清除缓存

    万次阅读 2020-03-17 20:27:42
    使用 pod cache list 查看看缓存 使用 pod cache --all 清除所有的缓存 使用 pod cache --all 清除所有的缓存 如果上传 pod 库成功了 但是却搜索不到这个库 可以在终端进行以下操作 1.pod sutup 2.rm ~/Library...
  • CocoaPods pod install/pod update更新慢的问题

    万次阅读 热门讨论 2014-09-05 17:01:46
    最近使用CocoaPods来添加第三方类库,无论是执行pod install还是pod update都卡在了Analyzing dependencies不动 原因在于当执行以上两个命令的时候会升级CocoaPods的spec仓库,加一个参数可以省略这一步,然后...
  • k8s 查看 删除,更新POD信息

    千次阅读 2018-04-13 16:37:51
    查看所有POD:kubectl get pod查看某个POD: kubectl get pod name以JSON格式输出POD信息: kubectl get pod name --output json以yaml格式输出POD信息: kubectl get pod name --output yaml删除某个POD:kubectl ...
  • kubernetes 自从1.7开始,可以在pod 的container 内获取pod的spec,metadata 等信息。具体方法可以通过env获取: env: - name: MY_NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName ...
  • pod install与pod update的区别

    万次阅读 2016-08-15 00:52:40
    1. 当你需要向向你的项目中安装新的pod库时使用`pod install`。即使之前你已经有一个Podfile并且执行了pod install,即使你是在向一个已经使用了CocoaPods的项目中添加或移除pod库。 2.只有当你想要更新pod库的版本...
  • pod install --no-repo-update

    万次阅读 2014-12-19 09:57:01
    最近使用CocoaPods来添加第三方类库,无论是执行pod install还是pod update都卡在了Analyzing dependencies不动 原因在于当执行以上两个命令的时候会升级CocoaPods的spec仓库,加一个参数可以省略这一步,然后...
  • 1、查看指定pod的日志 kubectl logs kubectl logs -f #类似tail -f的方式查看 2、查看指定pod中指定容器的日志 kubectl logs -c PS:查看Docker容器日志 docker logs
  • pod install速度慢的终极解决方案

    万次阅读 热门讨论 2015-12-30 11:08:06
    pod install速度慢的终极解决方案
  • SD模块中POD功能使用方法

    万次阅读 2015-11-30 14:52:19
    POD 在某些行业,销售发货给客户,中途可能有损耗。发货数量与客户收获数量不等。例如液体或散装物等等。 这样的话,开票数量要根据客户确认数量而不是发货数量,而交货成本还是根据交货数量来算。 VLPOD 交货证明
1 2 3 4 5 ... 20
收藏数 115,946
精华内容 46,378
关键字:

pod