国内至国际骨干ISP线路整理（转载） 国内至国际骨干ISP线路整理转自：https://www.gd1214b.icu/post/qfDddx_kZ/前言本文主要探讨的是IPv4网络，对于IPv6网络，那就是另一个故事了~ 我想在整理完此文后，对几条重要的线路单独拿出来说一说，我会直接拿接入该线路的VPS来做测试，来最大化给读者可视化线路质量。此文采用CC BY-NC-SA 4.0协议，可自由摘取片段用于非商业用途分享。国内几大骨干网介绍目前国内有三大ISP，电信、联通、移动，电信有2大骨干网——163和CN2，联通有2大骨干网——169和A网，移动只有1个骨干网CMNET，一共有5大骨干网，这些骨干网都有自己的独立国际出口，和国外ISP有直接Peer或Transit。另外有用于科研和教育用途的2个小型骨干网，CERNET（教育网，主用于高校）和CSTNET（科技网），这2个骨干网也有自己的独立国际出口，但是总体规模远小于电信、联通、移动，故能承载的出国带宽有限。电信的163骨干网自治系统编号 AS4134电信的CN2骨干网自治系统编号 AS4809联通的169骨干网自治系统编号 AS4837联通的A网骨干网自治系统编号 AS9929移动的CMNET境内骨干网自治系统编号 AS9808移动的CMI境外骨干网自治系统编号 AS58453CERNET骨干网自治系统编号 AS4538CSTNET骨干网自治系统编号 AS7497要注意一点的是，CMNET并没有和国外ISP有直接的互联，而是借助其境外骨干网CMI进行互联的。显然，如果我们只是了解到这里，对于后文的很多内容，读者还是无法理解，所以我们还需要知道这些骨干网更详细的信息，让我们一个个来看。以下的各AS BGP互联图来自 bgp.he.net ，版权归Hurricane Electric所有。如果对此已经完全熟悉的朋友建议直接跳过下面这段介绍AS4134 CHINANET 中国电信163骨干网宽带业务范围：普通家用宽带、商用宽带、政企宽带海外加速的专有业务：163精品网套餐（上海地区）已知出口：北京、上海、广州全国规模最大的骨干网，享有最大的国际出口，如果读者办理的是一般性的电信宽带又或者是商宽，访问境外网站，如果对方ISP没有购买电信的CN2 Transit，那么就走这个骨干网。AS4809 CNCN(CN2) 中国电信第二代骨干网宽带业务范围：家用游戏及海外加速宽带、商用跨国优化宽带、政企宽带海外加速的专有业务：CN2国际精品网套餐（覆盖几乎全国）已知出口：北京、上海、广州、乌鲁木齐技术先进，一般到一个ISP有不止一个Policy可以到达，灵活性非常高，因此可以提供稳定快速的国际互联服务，一般对海外聊天、游戏有较高需求的都会使用该网。目前该网是国内到国际网络高峰期能提供最好速率和体验的骨干网之一。AS4837 China Unicom BackBone 中国联通骨干网宽带业务范围：家宽、商宽、政企宽带海外加速业务：尚不明确，或当前未推出已知出口：北京、上海、广州如果是联通用户，除非访问的对方ISP购买了电信CN2 Transit/联通的CU Premiun，否则一律走169骨干网。该网目前出国拥堵程度小于电信163，但是总体速度和延时可靠性不如CN2。因价格便宜实惠，一般被很多游戏爱好者（国际服玩家）以及对普通外教课程有需求的首选宽带。通常我们这些Player也会更多倾向的考虑联通宽带，因为目前到国际网络普遍较好的就是联通的169骨干网。AS9929 CHINA UNICOM Industrial Internet Backbone 中国联通工业互联骨干网宽带业务范围：商业宽带、政企宽带海外加速服务：本网专做海外加速服务已知出口：北京、上海、广州本网前身为网通的骨干网，后与联通合并后改为联通A网，联通将该骨干网用于国际互联加速服务，价格昂贵，主要是跨国企业在使用，该网已无家宽业务。AS9808 China Mobile 中国移动骨干网宽带业务范围：家宽、商宽、政企宽带海外加速业务：尚不明确，或为高Qos商宽/机房宽带已知出口：北京、上海、广州AS9808为移动境内的骨干网，未设与国际ISP Peer，故所有出境流量通过AS58453（CMI）与外网互联。AS58453又被称之为CMI，是移动的国际段骨干网，最早只在香港建网，并接入HKIX，后逐渐扩大至全球。移动骨干网现如今已经不再具有国际出口优势，目前三网中只略好于电信163。只有高Qos的宽带才可以体验到17年前移动最初的乐趣。AS4538 CERNET China Education and Research Network 中国教育研究网络宽带业务范围：各大高校的校园网和部分大型国内云服务提供商已知出口：北京清华大学该网不服务于家宽、商宽、政企，一般来说，只有大学生和大学教授才会经常接触到这个网络。国内ISP与国际ISP的互联详情亚太地区中国香港常见ISP：CMI、CUG、NTT、PCCW、Telia、Telstra、CHT、HKBN、HKT、WTT、HGC、GTT、TaTa、HE、Cogentco、SingTel常见IX：HKIX、EIEHKG（Equinix Internet Exchange HongKong）常见下游：Cloudflare、Amazon、Azure、Google、CDN77、Cera Network该地区ISP连接质量排名（仅供参考，有些线路走不同的汇聚层会有不同的质量）：AS4134：CUG > CMI > Telstra >Others（对于163来说，只有CMI、CUG、CN2才可以不被严格的Qos限速，其他163直连的ISP在高峰几乎都一致性地失速，再往后比较就没有意义了）AS4837：CUG > CMI > PCCW > CHT > HKBN/WTT > HKT > OthersAS58453：CMI > CUG > SingTel > HKIX > NTT > HKBN/WTT > Others我相信对于很多南方地区的用户来说，对于需要访问一些全球类的网站，离得最近的CDN网络都是在香港（延时最低）。香港机房一直都是很多面向亚太地区服务器托管商的兵家必争之地，所以也涌现出了大量的IDC商家，可惜虽然鱼目混杂，但是能做到价格便宜且到国内直连的却少之又少，直连高昂的宽带单价也劝退了大部分商家。截至目前，只有国内大厂如阿里云、腾讯云敢大规模对外提供到国内直连的低价的香港轻量云服务，把价格从千元价位瞬间杀至2位数，但是因为需求量极大，而不得不严重超售宽带——极大的延时抖动，随机不确定的丢包，这使得对于托管在腾讯云、阿里云香港的网站的访客来说体验并不好。CMI - 移动自己的国际骨干网由于CMI自己也在卖香港资源，所以有些下游会选择直接购买CMI的Transit，来获得高Qos的CMI体验，这样国内用户到这些下游提供商就可以全部走移动的骨干网，来获得高性价比且高质量的访问体验。境内连接质量：非常高，只要对方下游接入了足够的CMI Transit宽带，峰值宽带基本是移动保证的。无论是电信、联通还是移动（当然移动用户访问过去，优先级是最高的）。虽然高性价比，但是毕竟是香港地区，流量单价依旧远超美欧Transit的单价。CUG - 联通自己的国际骨干网感谢知友@Mushroom Kinoko提醒，已经修正。同移动的CMI，联通也卖香港资源（自治系统编号AS10099），很多下游也选择接入了CUG的资源，这对于联通用户来说，等于获得了很好的质量保证。境内连接质量：非常高，只要对方下游接入了足够的CUG Transit宽带，峰值宽带基本是联通保证的。无论是电信、联通还是移动（当然联通用户访问过去，优先级是最高的）。NTT（香港）可直连的国内骨干网：AS4809、AS58453在香港地区，只有电信CN2、移动可以直连，其中电信CN2买了NTT Transit 。其余电信163和联通169都会绕路日本和美国，详见NTT（日本）和NTT（美国）。连接质量：需要注意的是，CN2很多时候不是万能的，特别是香港地区。CN2到香港NTT不可靠，有时候会爆炸，延时会呈现剧烈的抖动，如果需要追求高稳定性，不推荐CN2用户使用接入香港NTT的网络。移动如果不买他们的商业高Qos宽带，在高峰时期直连NTT会被Qos，丢包和延时都会显著增加，速度一般无法超过10Mbps。对于高Qos的移动用户也并不乐观，高峰时期，因为上海和广州地区汇聚层拥堵显著，所以最高速率往往也无法超过200Mbps特殊CM2精品网大客户除外，此类客户购买了移动的国际加速业务，移动优先保证此类 VIP 付费客户的宽带，Qos等级仅次于移动内网业务的必要控制流量，是所有运营类宽带里最高的，故除非PoP塞爆，否则在CMI和各大ISP的Peer下都会极力保证合同签约速率，哪怕是NTT、Cogent这些平时流量极大的网络都可以做到插队绿色通道。PCCW（香港）/HKT可直连的国内骨干网：AS4134、AS4809、AS4837、AS9929、AS58453我们平时接触PCCW的机会很多，PCCW也有一个负责国际优化的网络PCCWG （G=Global），我们平时遇到的商家一般接入的都是PCCW（非含G的网）。其实PCCW的效果在平时是被夸大的，就算是线路可以直连实际综合连接效果也仅仅是一个平均水平。电信163（AS4134）到香港PCCW是否直连看本地电信网络是否有自己的AS号，比如北京电信的AS4847城域网，上海电信的AS4812城域网等。一般来说，如果该地网络有自己的城域网AS号专门管辖，除非商家有特别优化，那么一般到香港PCCW不直连，否则如果是直接位于AS4134上一般会直连。电信网络到PCCW一般只有北京和广州两个汇聚层可达，上海汇聚层不可达，高峰丢包较高，速度不理想。联通169（AS4837）联通到香港PCCW可能绕美，原因和电信部分相同，不再赘述。直连的情况下，联通到PCCW效果要远远好于电信，处于可用的状态。联通A网（AS9929） 网络质量基本是这么多网络里面连接到PCCW最好的，延时抖动也是最低的。但是9929的价格比CN2都要贵上好多倍，一般没有点钞能力是用不上的...移动的CMI（AS58453），如果没有商家优化，移动会随机把路由发往美国、日本、香港三地，以实现流量平衡，在用户看来，这就导致延时时高时低，非常不稳定，不推荐移动使用。同时，HKT隶属于PCCW，所有的国际出口都是走PCCW/PCCWG的。HKT因为可以走上PCCWG和德国地区直连，所以也被称之为打机神线。但是普通的HKT家宽/静态根据段不一样，联通169可能绕韩国KT，也有可能直连；联通9929通过PCCW与HKT互联。Telstra Global（香港）可直连的国内骨干网：AS4134、AS4837、AS4538、AS9929、AS58453这个网络我相信教育网用户会比较熟悉，Pacnet就是Telstra的，Telstra 承担了教育网的亚太地区的主要出口。Telstra是为数不多三网都可以直连香港，对我们很友好的ISP。哪怕是电信163也可以在香港地区直连Telstra，高峰速度也算是电信163网络中顶级的了，我一向非常推荐Telstra，于是在此反复安利了。另外，Telstra也是电信163到亚太地区（特别是印度、澳大利亚、新加坡）低延时的性价比解决方案。Traceroute to India Telstra Global联通的169网络到Telstra也不差，在香港的直连宽带很大，高峰情况，据近一年的SmokePing数据来看很稳定，如果想要搞一个新加坡的VPS，选Telstra线路的也不差哦~（香港的Telstra线路的VPS很少）AS9929与Telstra Global有Peer，高峰速度非常可观。香港Telstra和移动CMI的互联就比较拉垮了.... 整体互联宽带相比与NTT、HKIX而言相形见绌，这也为高峰的延时猛涨买下了伏笔（互联宽带一旦打满，数据包需要排队等待，延时立即升高）。较小的宽带会影响线路的稳定性，如遇DDOS塞满PoP，延时和丢包也会使得网络瞬间不可用。所以移动用户决定要用Telstra线路的服务器来搞事情之前最好深思熟虑一下 - -CHT（香港）可直连国内骨干网：AS4134、AS4837、AS58453CHT即中华电信，为中国台湾的第一大ISP，拥有2大骨干网（CHW「 HINET」、TWGATE），我们通常说的Hinet即为CHW网络，CHW与TWGATE的关系可以参照电信163和CN2的关系。事与愿违，从几天前开始，电信163骨干网到CHW网络的效果急转直下，无论是低峰还是高峰的下载速度都只能用惨淡来形容。所以除非你有业务需求，否则我不推荐你把个人网站放在CHW下，高昂的成本价格现在无法匹配上其延时和速度，是个性价比很低的选择。相比于电信163的拉垮表现，联通169的表现就漂亮的多，差不多的延时却有着更低的丢包，更高的峰值速度。但是鉴于该地区很高的主机售价，如果你是一个联通用户，CHW也未必是最佳的选择。也别对移动CMI抱有太大的期望，在低峰和高峰表现截然不同，高峰常常极度拉垮，上面的Telstra好歹还是有速度，这个是真的一点速度都跑不出来，不推荐。HKBN/WTT可直连国内骨干网：AS4134、AS4837、AS58453HKBN都主要服务于香港宽带，故一起讨论了，目前没有看到亚太其他有接入它们的案例。一般只有在流媒体解锁用途的时候会用到它。HKBN三网可以直连，由于没有资料表明HKBN拥有强大的国际骨干网，这两家也没有什么特殊的地方，故点到为止。HE（香港）可直连国内骨干网：AS58453（Through HKIX）、AS9929（via HKIX）移动可以通过HKIX直连HE香港，但是该操作需要IDC调整路由表，否则移动默认连接香港HE会绕美。联通9929同样也是通过HKIX直连HE香港。曾经是走CUG的HKIX互联，如今是走联通9929自己与HKIX的互联。爆炸绕路三幻神之一，所以对于电信、联通169和教育网来说，都会绕美，故详见HE（美国）。TaTa（香港）可直连国内骨干网：AS4837、AS9929电信163网络原先和Tata在香港有Peer，但现在基本不走了，具体原因未知。联通和Tata在香港直连，大部分情况下回程绕美，安徽联通商宽到香港GCP/台湾GCP（标准ip）回程走Tata直连。此线路出现的概率极小，联通4837和香港Tata存在带宽大约为600mbps的peer。在特殊优化下，联通9929可以经过TATA与CUG的Peer来得到直连。但是非优化线路哪怕跟CUG有Peer也绕美。不愧是爆炸绕路三幻神之首...Cogentco（香港）可直连国内骨干网：无爆炸绕路三幻神之一。Cogentco在香港地区没有国内的ISP可以直连。电信、联通9929、移动和教育网会绕美，联通169则绕新加坡，详见Cogentco（美国）、Cogentco（新加坡）GTT（香港）可直连国内骨干网：无GTT在香港地区没有国内的ISP可以直连。三网均会绕美，详见GTT（美国）中国澳门常见ISP：中国电信（澳门分公司）、CTM、MTel中国电信（澳门）中国电信自己在澳门经营的分公司，国内全部网络都可直连，走AS4134或AS4809（GIA）。CTM可直连国内骨干网：AS4134、AS4837、AS58453并非所有IP都直连，非大陆优化的国际网络都不直连CTM是澳门最早成立的电信公司，在澳门地区提供上网服务，目前仍旧是当地规模最大的ISP。CTM很早就和电信163、联通169互联，网络质量可靠，但是CTM的机房托管业务把网络分为了2类，一类是国内优化，即提供国内直连路由，一类是更加便宜的国际路由，这类路由不提供国内直连。目前市场上比较平民的澳门VPS都是国际路由，并未针对国内优化。移动则是在后期不断扩张中涉及澳门移动上网业务，后在澳门建设PoP，但澳门PoP只和香港PoP相连接，所以移动用户如需访问澳门CTM需要先经过香港方可到达，延时自然就不如前者低（大约多了6ms）。MTel可直连国内骨干网：AS4134、AS58453MTel于2011年成立，是所有澳门经营的电信公司里资历最浅的。MTel和中国电信163目前已经实现互联，但因容量很小，导致互联效果不佳——澳门MTel和中国电信163的互联经常打满，延时波动很大，晚高峰受限于整体互联宽带大小，速度也无法令人满意。联通绕日本NTT，主要取决于联通到日本NTT的表现，移动走自家的澳门PoP，主要取决于CMI是否给力。中国台湾常见ISP：HiNet、TFN（台湾固网）、SeedNet、TaNet（台湾学术网络）、HomePlus（中嘉宽频）常见IX：TWIXHINET可直连国内骨干网：AS4134、AS58453、AS4837其中 AS4134 和 AS4837 延迟都明显要比 AS58453 高一些。广州移动延迟大约 40ms，武汉电信家宽环境中延迟大约 50ms~60ms，北京电信商宽大约 70ms，上海联通商宽延迟大约170ms，长沙联通商宽延迟大约140ms。HiNet是中华电信（CHT）的一个品牌，也是全台湾最大的宽带提供商。目前台湾地区的主流流媒体解锁都是用了HiNet动态IP（家宽）以及静态IP（商宽、IDC）来解锁的。HiNet拥有整个台湾地区最大的电信骨干网，也是国内出口流量最大的ISP。CHT另拥有一张TWGate的网络，专注国际互联，其性质相当于中国电信的CN2。TFN台湾固网SeedNetTaNetHomePlus日本常见ISP：NTT、IIJ、KDDI、BBTEC、Telstra、PCCW、BGP.NET常见IX：JPIX、BBIX、EIEHND（Equinix Internet Exchange Tokyo）常见下游：Cloudflare、Amazon、Azure、Google、M427、xTom日本的宽带业务竞争激烈，导致ISP提供商不得不杀出更低的价格来吸引客户，但是往往事与愿违——用户的口碑却更糟糕了。比如，和阿里巴巴合资的SoftBank（软银）公司创立的ISP服务商——BBTEC，看起来是一个不错的选择，实际晚高峰网络拥堵，体验很差劲，试想如果发条消息都要卡半天的话，真的是一件很让人抓狂的事情呢。不仅是家宽，商宽乃至服务器机房，接入一条ISP线路的成本价格都不菲，况且很多日本IDC只对日本本国居民提供服务，所以催生了很多代办业务，最有名的就是樱花机房的服务器代办服务。往往只有这些对本土开放的IDC才有可能是原生IP（可以解锁当地的众多流媒体、游戏和网站，很有意义），所以哪怕要被代办收取高额的代办费，也会有很多有需求的人士会前去购买。NTT可直连国内骨干网：AS4134、AS4809、AS4837、AS9929、AS58423日本作为NTT的大本营，几乎全国的宽带服务提供商都有NTT的踪迹。因为NTT的骨干网覆盖了日本几乎所有能够覆盖到的地区。关于日本NTT，我想在文中说明的实在太多了，限于篇幅，我还是精简一下 - -...NTT和国内ISP互联时间很早，在2000年后，NTT和当时的网通互联，互联出口设在上海和北京，并在上海和北京分别建设NTT的PoP节点（少数国外ISP将PoP设在国内的案例）。值得一提的是，但是这是目前国内直连日本NTT延时很低且很稳定的渠道，CN2到日本NTT都干不过它，根据实测，目前NTT-9929的速度基本取决于用户接入的9929的带宽速度。中国电信163和日本NTT之间的扩容就勤快多了，电信还在日本东京设立了PoP方便和日本本土ISP快速互联。听起来很美好是吗？但是这不妨碍电信163和日本NTT之间日常大爆炸（里面大部分都是被巨量的DDOS流量打崩的）。绝大多数情况下，163-东京NTT、163-新加坡NTT两线是163网络所有互联线路中质量最差的网络，没有之一。根据近一个月的监测记录，上海电信到东京NTT之间的平均延时（周期为半小时）在48~295ms之间抖动，高峰一小时平均丢包率峰值可达40%，高峰一分钟平均丢包率极限情况下达到了惊人的99%，这就导致了高峰哪怕绕美的体验都要强于直连。联通的169网络早期有2条路线可以前往日本NTT，一条是从北京-大阪，另外一条是上海-东京。虽然联通169一直普遍被用户认为国际出口质量很高，但是这2条NTT的线路也并非各位读者想的那么美好。北京联通169 - 日本大阪NTT该线其实最早是网通搭建的。联通收购网通后，便把网通的PoP拨给自己使用，直至今日，我们都可以在NTT在北京PoP IP的rDNS上找到来自历史的证明——129.250.8.26(xe-0.cnc-g.osakjp02.jp.bb.gin.ntt.net)这里的CNC，就是曾经的China NetCom（中国网通）的缩写，osakjp，指的就是日本大阪。xe是指骨干网路由使用的是Juniper公司研发的路由，每条线为10Gbps端口 。但是到了现在，由于联通也在不断开拓自己的国际市场，目前联通也在东京和大阪分别设立了PoP，只是目前往北京方向回程依旧在走NTT的北京PoP，往上海直接走的是联通在日本自己的PoP了。经过了最近的一番扩容和优化，北方联通169往日本NTT方向也有很大的改善（目前暂时停止北京-大阪该线路由，走上海），延时显著降低。虽然去程多绕了一点，但是延时下降了很多，还是可以接受的。移动作为后来者，前往日本NTT最早都是借助香港CMI出国，近两年才开通了日本东京的PoP，并用上了全新的NCP海缆才得以能够不绕港直连。但是目前移动到日本NTT都不走NCP，而是继续绕香港CMI，估计在不久的未来直连后会有更低的延时体验。IIJ可直连骨干网：AS4134、AS4837、AS58423中国电信的163与IIJ的互联是通过电信在东京的PoP实现的，国内可以通过三大汇聚层轻松访问PoP节点。互联的网络质量远好于和NTT的质量。IIJ是电信163用户造访日本网站最好的线路之一，目前已经胜过软银，不考虑高峰丢包和延时抖动，是性价比之选。中国联通169与IIJ的互联方式和电信几乎一样，但是综合来看要好于163与IIJ互联的质量。提供IIJ接入的IDC价格比较亲民的很多，如果不愿意接受软银的高价位的话，不妨试试IIJ。另外，教育网前往IIJ也会走联通169骨干网出国。目前移动和IIJ的互联已经通过东京移动的PoP来完成，故移动到日本IIJ不再绕香港而是通过NCP海缆直连东京的PoP后与IIJ完成互联，上海移动到东京IIJ参考延时为45ms（实际上可以做到32ms）。综上，IIJ是日本地区对我们比较友好的，也是价格相较于其他三家比较实惠的一家ISP，如果没有太小众化的需求，上国内走IIJ的VPS是很省心的选择。BBTEC可直连骨干网：AS4134、AS4837、AS9929、AS58423BBTEC（软银）其实是近几年才被我们注意到的一家ISP，在上海地区设有PoP并与电信163和联通169/9929互联。该线路一直被称之为联通到日本最好的线路之一。想要补充一点的是，9929早期和软银并没有直连Peer，而是借助4837（联通169）作为跳板实现的。而近期在路由测试中，我们可以清楚地看到软银和9929已经在上海PoP实现互联，但是在BGP ToolKit上都未显示2者有任何形式的互联，基本可以判断是Private Peer。电信163到软银延时相比于NTT属实较低，但是却同样跑不出什么速度来，延时最初是日本御四家里最低的，但是后来因为使用人数的增加，延时逐渐不如IIJ。联通169到软银的延时则相对不稳定，取决于去程走上海口和北京口，通常BBTEC回程经由自己的上海POP与联通互联。尽管联通和软银互联的优势已经不如以前，但是目前仍旧是联通到日本最好的线路之一。联通9929到软银的延时稳定，互联速度也取决于用户接入的9929带宽速度。如今，移动已经在日本的东京设立了PoP，所以从回程看，除了广州移动还是继续走香港CMI，其余均在日本就Peer，并由移动自己的骨干网负责流量回国承载。目前去程依旧全部绕香港CMI，这也导致北方移动延时的升高。总体来说，软银对北方移动不友好。KDDI可直连国内骨干网：AS9929曾经活在传说中的线路，价格昂贵，唯一的优势就是低负载，延迟一般40ms上下抖动。联通9929速度单线程只能跑到100Mbps左右。新加坡常见ISP：NTT、Singtel、Telstra、StarHub、MyRepublic、PCCW(G)、Cogentco、HE、Tata、CMI、CUG、BGP.NET、SG.GS常见IX：SGIX、EIESG（Equinix Internet Exchange Singapore）下游：OVH、Cloudflare、Google、AmazonNTT（新加坡）可直连国内骨干网：AS4134、AS58453正如你所见，NTT在亚太地区无处不在~ 所以我们一般把NTT视作亚太地区ISP的标杆，这已经成为了事实上公认的标准。在新加坡，NTT也拥有巨量的骨干资源，轻松连接新加坡所有的本地ISP。NTT也有多条新加坡至日本的海底光缆所有权/使用权，所以NTT可以借新加坡作为跳板，以此连接马来西亚、菲律宾、印度尼西亚、泰国、越南、缅甸、柬埔寨、印度等国，在其后我们也会讨论到这些地区的本地网络情况。中国电信163与2020年和NTT在新加坡正式建立互联，即意味着新加坡NTT从即日起无需绕行日本再与163骨干网互联，但是情况变得更加糟糕，因为新加坡地区的中国电信163和NTT互联宽带很小，所以几乎全天都处于被塞满的状态，延时异常偏高，丢包率极大，因此非常不推荐使用163连接新加坡地区的NTT。移动的CMI在新加坡有自己的PoP，同时在当地就可以和NTT互联，因互联宽带很大，所以目前没有看到被塞爆的情况，移动用户目前访问新加坡地区资源的主流渠道就是通过新加坡PoP。联通9929和联通169目前都不能直连新加坡NTT，请详见日本NTT。SingTel（新加坡电信）可直连骨干网：AS4837、AS9929、AS58453Update: 随着移动CMI Transit在亚太的高性价比的优势被挖掘，我们也可以看到大量走CMI的香港/新加坡VPS出现在市场上。这也是目前最具有性价比的大宽带亚太VPS，但是目前CMI的峰值流量已经达到其容量极限，如果依旧不能大幅度扩容的话，CMI在晚高峰的延时和丢包已经呈现显著增长的趋势。移动为了减轻自己的跨国骨干网压力，目前已经开始对于第三方ISP收取更高的Transit费用，第三方有些已经采用单向路由的方式来节省成本。对于SingTel来说，大陆->新加坡的这部分流量要远大于新加坡->大陆的流量，而现在拥堵的也主要是新加坡->大陆的这部分流量，所以目前SingTel已经断开了往大陆方向移动在新加坡的直连，改走更加通用的NTT。不过目前移动对自家网络CMI和NTT的质量部署了较为严格的限速策略，导致延时、丢包和速度表现均不佳。联通的169，在这里把“稳定”两个字表现的淋漓尽致，网络对于亚太的支持绝对可以称为老二，在新加坡地区，联通和SingTel有直接Peer，故整体延时和移动几乎一致，只要回程不绕路，使用SingTel也很棒，目前联通也是唯一SingTel双向新加坡直连的国内ISP。但是对于中国电信163来说，因163网络和SingTel在世界各地都没有Transit/Peer，这就导致前往新加坡SingTel之前，数据先会被发送至美西Tata/Telia，但是目前电信163和美西的互联早就已经满了（其实不只是163，CN2也满了），所以速度上来说非常糟糕，加上严格的动态Qos策略，使得延时和丢包雪上加霜。需要补充一下的是，新加坡SingTel是全新加坡最大规模的ISP，在非大陆地区的国际互联上面，SingTel还是有着相当大的优势，如果您在新加坡的话，选择SingTel还是最佳选择。Telstra Global（新加坡）可直连骨干网：这都香港直连了，还要什么自行车！由于接入Telstra的VPS大多在日本、澳大利亚、新加坡，而Telstra和国内御三家主要的Peer在HKG（香港），所以速度肯定差不多的啦~StarHub可直连骨干网：AS4134、AS4837、AS58453StarHub是当地一大本土运营商，提供宽带服务，因为规模较大，常用来解锁新区流媒体的用途。既然三网都在新加坡和StarHub有Peer，那么是不是就代表着StarHub到我们国内的表现非常优秀呢？实际路由表现并没有读者想象中的那么好。电信163去程是直连但是回程是绕路的，联通169回程是直的但是去程绕了日本NTT。只有移动比前两者好一些，通过新加坡EIE和Starhub互联，较于前者这种的优势在于IX中心互联非常方便对接IX内的所有网络，但是容量可能有限，难免高峰不爆炸。MyRepublicMyRepublic也是当地一大本土运营商，通常被用来解锁新区流媒体的用途。但是MyRepublic没有任何和国内御三家的互联，所以最好使用移动CMI或者CN2中转。中国电信163、中国联通169网络走NTT，移动走新加坡EIE至StarHub再转MyRepublic。Cogentco可直连骨干网：AS4837近日，中国联通169在新加坡地区和Cogentco开通了新的Peer，使得很多亚太地区Cogent单栈的宽带/服务器都焕发了新的生命，通过联通的169网络，可以做到广州联通到新加坡Cogentco 46ms的延时成绩。Tata可直连骨干网：AS4387、AS9929(从AS10099接入）Tata在新加坡与联通存在peer，可经由AS4837直连广州入口，目前已知经过新加坡Tata到联通的线路几乎都是孟买一带的机器，例如Linode、阿里云、腾讯云等马来西亚常见ISP：TMNet (unifi) 、TIMEdotCom (TIME MY)、EBB.MY (Extreme Broadband) 、Allo Technology (City Broadband) 、Maxis Communications Bhd 、Celcom Axiata Berhad 、PCCW(G)、HE、Tata、CMI常见IX：MYIX (The Malaysia Internet Exchange) 、JBIX (Johor Bahru Internet Exchange (JBIX))下游：Cloudflare、OVH、MSCHosting (Exabytes)、U Mobile 、DiGi Telecommunications (Telenor)、MYREN (Malaysian Research & Education Network)马来西亚所有的ISP几乎都对中国移动友好，有些是在 Equinix SG 转一圈后接入 CMI , 有些是接入 NTT 新加坡 后到 NTT HK 再到 CMI HKTMNet (unifi)TMNet (unifi) , ASN 为 4788 , 是全马来西亚数一数二的ISP , 几乎垄断马来西亚近70%的固定宽频市场，常用来解锁马区流媒体的用途可直连骨干网： AS4134 中国电信中国联通会从新加坡接入 HE.Net 后绕到美国HE.Net 再接入中国大陆中国电信通过TM接入中国电信日本后接入中国大陆CN2 经由Singtel SG 后跳入广州中国移动先是到 Equnix SG 再到 CMI 再到 AS9808和 TIMEdotCom (TIME MY) 的互联很烂，经常出现晚高峰 100ms + 的情况国际网络质量偶尔抽风和 OVH 新加坡拥有peeringTIMEdotCom (TIME MY)TIMEdotCom (TIME MY) , ASN 为 9930 , 是全马来西亚除 TMNet (unifi) 第二大的ISP，提供的家宽配套无论是在速度还是价钱都吊打 TMNet(unifi) , 双向500Mbps带公网IP家宽只需210+人民币，在马来西亚算很便宜了，目前市面上没看见 TIMEdotCom 的VPS，不过可用来解锁马区流媒体可直连骨干网：IPV4 : N/AAS9808 会经过:NTT SG - NTT HK - CMI HK - 9808HE.NET KL - HE.NET SG - Equinix SG - CMI Guangzhou - 9808163 骨干网和 TMNet (unifi) 情况类似，会转发到 Tata :Tata SG - Tata JP - Tata US - 163 骨干网CN2 会经过 HGC HK 接入大陆 CN2AS4837 都会经过 SingtelIPV6 : AS4134仍不确定 TIME 跟 中国电信买了多少容量可是通过路由可以发现是直接从马来西亚 TIME 骨干网跳入中国电信新加坡 PoP , 后直接到中国大陆电信骨干网AS4837 : 去程经过 NTT SG - NTT 日本 - 中国大陆目测回程绕美 ，延迟可达200ms +其他ISP基本都半斤八两:Maxis 上 AS4837 同样走 SingtelDigi / U Mobile 靠AS4788 作为上游所以线路基本和AS4788一致Allo Technology 最大上游为 Cogent , 也有接入 TMNet , 不排除部分线路走 TMNet 过 , IPV6 最大上游为 HE.NetEBB.MY 基本靠 HE.Net 做上游，移动/联通/电信都不讨好，不过可以直接接入 CN2总结：马来西亚ISP基本都对中国移动友好，极少ISP (比如 Maxis / TIMEdotCom) 在连接中国联通时走的是 Singtel 直连，不过延迟90+ , 有可能回程绕日本市面上目前也就 TMNet (unifi) VPS , 仍未见到类似 TIMEdotCom / Maxis 的VPS韩国常见ISP：KT、SKT、LG （绕路的ISP:NTT、PCCW、Telstra Global 绕日绕港绕新加坡 故不测试）常见IX：KINX常见下游：Moack、Oracle、Cloudflare、Amazon、Azure韩国本土网络发达，除了三大ISP以外还有地区性ISP，大陆地区前往韩国主要走TPE、APG、APCN-2、NCP四大海缆。国际路由差强人意，但靠着CDN也足够应付。但到中国大陆的带宽与路由不尽人意，绕路与直连汇聚层日常性堵塞层出不穷，丢包与抖动比较严重（虽然没有到163-NTT那么夸张）。同时韩国的互联网管理相对严格，购买上比较麻烦。KT可直连骨干网：AS4134、AS4809、AS4837、AS9929、AS58453KT（Korea Telecom），韩国最大电信运营商，市场占有率排名第一。目前电信163/CN2和韩国KT之间的互联是通过APG海缆完成的，因为APG海缆只在上海有登陆，所以目前前往韩国KT都是走上海出口。需要注意的是，无论是电信163还是CN2和韩国KT的互联宽带均有限，高峰汇聚层没炸先Peer炸了也是经常发生的事情。电信163至韩国KT的速度在Peer不被塞满的情况下单线程能跑100-200Mbps，晚高峰受限于汇聚层和Peer宽带的双重因素影响，速度受限比较严重。CN2虽然不用太担心汇聚层的拥塞问题，但是目前的Peer宽带依旧是比较主要的速度和延时等稳定性制约因素。联通9929与KT有互联，同样也是走上海出口。高峰期几乎无丢包，延迟极低，单看极限最低延迟逼近沪韩IPLC；可惜经常抖动，虽然幅度不超过5ms。速度方面也属于跟日本ISP到9929一样，KT到9929的速度取决于用户接入的9929带宽速度。近期似乎扩容/更新设备了，抖动大幅降低。根据测试。KT-广州移动（120.197/183.240段）高峰期速度非常不稳定，回程路由绕港。SK Telecom可直连骨干网：AS4134、AS4809、AS4837、AS58453SKT可能从某种意义上知名度比KT高，SK Telecom是韩国最大的移动网络业务运营商。实际上提供网络服务的是SKT的旗下公司SK Boardband。这一点可以从ASN信息中看出。SK - 163 答案很简单，走上海出口直连但是会BOOM，包括163+...SK - CN2 非常稳定，有Peer，任何时段基本没有丢包但看起来绕港，速度不稳定。SK - CU169(上海)时延会在高峰期会振荡，速度也飘忽不定，但配合单边加速还算可用。CMI与SK Boardband在香港Peer，移动经香港到CMI可以与其直连，到广东移动的速度飘忽不定。LG可直连骨干网: AS4134、AS4809、AS4837、AS9929韩国第三大ISP,现名LG Uplus，曾用名“Intergrated LG Telecom”。LG的电信发展历史基本上就是一场收购史……LG Uplus 由三家LG子公司合并而来，分别是LG DACOM，LG Powercom和LG Telecom。其中LG DACOM和LG Powercom又是收购而来。原来的LG Powercom负责运营民用网络，从韩国电力收购而来；LG DACOM负责国际通信业务，也就是LG的国际路由上会出现DACOM的原因。DACOM全名为DataCommunication，由韩国政府牵头，LG与三星共同投资建设，但拥有独立经营权的ISP，后因为LG额外注资增持股份，LG完全接管DACOM。而LG Telecom则是LG自己独自投资建设的移动网络。LG到联通169（上海）直连，走上海出口，配合单边加速高峰期速度不错。但ICMP丢包率特别高。LG到联通9929是直连，同样走上海出口。但奇特的是虽然延迟也很低，速度却非常不稳定，隔三差五就突发性的延时起飞；但是正常的时候又十分平稳，几乎没有抖动，可速度依旧不尽人意。越南常见ISP：VNPT、FPTVNPT可直连骨干网：AS4134、AS4837、AS58453作为全越南最大的电信ISP，VNPT拥有着全越南最大的骨干网和国际出口，但是一般很少有人会拿越南的宽带做流媒体解锁服务。虽然电信163和VNPT互联（广州出口，胡志明市PoP），但VNPT的网络质量本身就不是很可靠，导致高峰没有速度乃是常态。最近VNPT还把回程的163直连路由改成绕路了（到香港后转PCCW，但PCCW到电信现在默认会绕美），使得电信163和VNPT的网络单向互联意义不大。电信163也和VNPT在香港地区以CTG（中国电信国际）的名义互联，但少有可以走到这条线上的，而且回程依旧绕PCCW，导致目前两条与VNPT互联的线路都是单向路由。电信163最神奇的地方莫过于，并不是所有的VNPT IP段都会走上述2条互联，也有可能会走美西的Tata亦或是走欧洲的Cogent借助胡志明的BICS接入VNPT。联通169到VNPT也通过胡志明市的PoP互联，但是和电信163一样，也是单向互联，回程绕PCCW。移动CMI在香港和VNPT互联，常规操作，感兴趣的可以翻翻香港地区的ISP是怎么和移动互联的就知道了。FPT可直连骨干网：AS4134、AS4837、AS58453如果说VNPT到国内御三家都不怎么友好的话，那么FPT应该是到越南地区非常友好的ISP了。电信去程163会走联通的网络去和FPT互联，回程走香港CTG回国，但是宽带很小经常爆炸，不爆炸的时候速度很快，期待以后的扩容。因为FPT接入了CUG，所以联通169到越南FPT走的是AS4837->AS10099->FPT，虽然CUG很可靠，但是依旧受限于FPT接入宽带的容量，晚高峰几乎天天爆炸，这个只能等FPT扩容。移动CMI和VNPT一样，都是常规互联，晚上也炸的很厉害。我后期还会在这里添加日本、印度尼西亚、菲律宾、泰国、印度、孟加拉国、柬埔寨、泰国、尼泊尔等国家。欧洲/北美地区欧洲/北美的网络情况跟亚太差异比较大。欧美的中小ISP大部分依靠的是IX互联或者机房托管的混合网络接入。虽然商业网络的价格比亚洲地区便宜，但至少对中国用户来说，很少再回程路由中遇见欧美的Regional T1或者高质量T1 ISP。比如说在欧洲的Orange(前身法国电信France Télécom,AS Rank 11),Vodafone (总部在英国,AS Rank 12),Deutsche Telekom(德国电信AS Rank 24),北美的ATT(AS Rank 20) ,Verzion(AS Rank 21) ,Sprint(AS Rank 26)。题外话，BT(英国电信)反而是Regional T1,AS Rank比中国电信还低。欧洲德国DTAG可直连骨干网： AS4134、AS4837、AS9929Deutsche Telekom AG ，德国电信，德国第一大ISP，T1级。旗下移动运营商T-mobile相比于DTAG更加知名。DTAG于AS4134和AS4837均有peer。同时也是AS9929上游。但延迟均200+起跳。电信163普通家宽会被强制丢包，而163plus能保证相对稳定延迟与相对较低的丢包联通169则取决于汇聚层是否拥塞。非拥塞状态则能保证网络质量。但是只限于北方地区的联通（如河南/山东等）。南方地区的联通（如上海）将会被无慈悲的绕美，由DTAG转发Level3。AS9929依旧稳定发挥，甚至延迟优于AS4134 AS4837,但速度很勉强，几乎稳定80Mbps。Cogent CommunicationsCogentco由于在Traceroute上的细节写的过于清楚明白，以至于有一部分以为跳数越多越差人觉得Cogentco不行。虽然它也确实不太行...可直连骨干网：AS4134、AS4837、AS9929、AS58453。Cogentco,联通9929真正的互联主力……几乎绝大部分的欧美线路到9929都会被Cogentco宣告。以至于在欧洲会出现回程不走DTAG硬是跑Cogentco外加联通9929的NOC基本不会主动调整欧美路由。速度十分玄学，单线程在50Mbps摇摆，多线程却接近跑满。美国洛杉矶&圣何塞洛杉矶和圣何塞是美西重要的面向亚太地区的互联网PoP中心，TPE海缆多从此处2点接入。中美之间的互联占据了出境流量很大的一部分，也是电信163出国的主要路径。HEHE，全称为 Hurricane Electric（飓风电气），目前是坐拥全球以Peer数量计算的最大IPv6骨干网的ISP，骨干网自治编号为AS6939。HE也提供免费的IPv6 Tunnel，以方便IPv4单栈的用户能够无障碍地访问IPv6网络。HE的发展思路一直是竭尽全力和世界上更多的ISP Peer，尽管获得了非常多的本地互联，但是因自身前期在亚太骨干网投入不足，导致和一些ISP对等宽带过小、跨洋传输场景下的宽带传输速率有限，HE也一直在努力扩容，可惜仍旧有较大缺口。我们看到的亚太地区（香港、新加坡）的低价VPS产品线，几乎都一致地选择了HE作为唯一的互联网接入，而且接入的宽带并不大，平均1Gbps。但是哪怕是HE这样的ISP，在亚太地区的BGP Transit也颇为昂贵，这些商家为了能够有所盈利，在超低的VPS价格上，宽带上面必须大幅超售，这些反而给低端用户群体带来了十分糟糕的用户体验，很多时候，这些VPS访问外网速度慢不是HE的问题，而是IDC没有购买足够的宽带导致。作为对等节点极多的HE来说，IPv6网络下和中国大三ISP均有直接互联，也是当下国内IPv6网络跨国的主要对等ISP，为推动全球IPv6互联中扮演着非常重要的角色。可直连骨干网：AS4134、AS4837、AS58453电信163和HE在洛杉矶有10～20G的互联，平时鲜有出现较大的延时抖动，但是速度限制较为严重。联通169和HE的洛杉矶互联通常被视为在廉价互联里面很具有性价比的，相比于联通169和GTT的互联，和HE的互联质量就要好很多，很多用户也在尽可能选择更价廉物美的选择。CMI与美西的互联一向较差，并不具有较好的连通性，再加上HE和CMI的互联本身就炸的比较厉害，此条线路不推荐移动去尝试。GTTGTT，前身为Global Telecom and Technology，自1998年成立以来，在跨国电信业务上耕作至今。可直连骨干网：AS4134、AS4837、AS58453联通169在美西较大地依赖GTT的互联，导致延时相比正常美西延时高很多，速度并不乐观。电信163和GTT的互联却是出乎意料的好，根据SmokePing的结果，电信163和GTT的互联全天几乎不丢包，完全受限于汇聚层是否通畅。这就意味着只要使用高Qos的电信宽带就可以获得较好的速度。TeliaTelia是瑞典最大的电话和电信通讯公司，前身为瑞典电报局及芬兰电讯。现更名为Arelion，但目前在路由上的名称依旧是Telia。可直连骨干网：AS4134、AS4809、AS4837、AS58453Telia在美国、欧洲都有和电信163互联，总体来说是很中规中矩的线路，Cogent Communications可直连骨干网：AS4134、AS4837、AS9929、AS58453跟欧洲情况差不多。电信163在美西较大程度上依赖Cogentco的互联，爆炸的几率较高。Verizon可直连骨干网：AS9929联通9929与Verizon的互联一言难尽，延迟不是最优，单线程速度也不是最优。高峰期单线程速度在50-70Mbps震荡。而多线程速度倒是能跑满，非常的玄学。有时候其他北美ISP到联通9929需要经Verizon转发，而被转发的速度就很难保证了。非洲地区肯尼亚常见ISP：LiquidTelecom可直连的骨干网：AS4134、AS4809、AS58423LiquidTelecom在肯尼亚设有非洲国际交换中心，后与中国电信签署合作关系，目前中国电信在肯尼亚设有一处PoP，同时接入了163和CN2网络，和LiquidTelecom都有Peer。LiquidTelecom也是非洲北部最大的ISP，在非洲拥有100GE的骨干网，可以说是非常强了。电信163前往该PoP需要先在新加坡的163 PoP中转，后前往非洲。在世界各地有自己的骨干网以及PoP，这就是为什么中国电信现在越来越被认可为Tier 1的原因。虽然听起来特别厉害，但是实际上163网络到肯尼亚直连很差，不过这并不是因为LiquidTelecom导致的，电信的163汇聚层拉垮是主因。从肯尼亚CN2的表现，严格的来说，是达到及格线的，但是价格昂贵，一般很少有人会去选择那么偏僻的CN2，我也只是找到了没几个段的肯尼亚CN2 IP段，通过SmokePing检测观察许久得出来的结论。联通和移动都没有和LiquidTelecom直连，所以都绕路。南非在南非，一共有三大IX，JINX、CINX、DINX（约翰内斯堡互联网交换中心、开普敦互联网交换中心、德班互联网交换中心） ，这里我们主要讲JINX，别的基本和我们的御三家无关。我们可以看出电信的非洲地区是下了功夫的，JINX也设有电信的PoP，同时接入AS4134和AS4809，这个网可能听说的人比较多，Misaka的南非约翰内斯堡的服务器网络就是接入了JINX和电信CN2互联的。说实话，因为联通、移动没有想过在非洲布局，所以这个地区基本没他们什么事...中东地区阿联酋常见ISP：du.ae可直连的骨干网：AS4134、AS4809du.ae 是当地一大电信ISP，骨干网覆盖全国，在阿联酋的迪拜电信设有PoP，同时接入电信163和CN2。电信依旧是通过新加坡的PoP中转以连接阿联酋，根据Ucloud的阿联酋地区长达一个月的TCPPing数据，该地区163网络要比南非肯尼亚LiquidTelecom稳定，CN2可以实现132ms的低延时。后记洋洋洒洒写了1万多字，但是发现还有许多地区未能来得及覆盖到，后面继续追更吧~ 虽然很多地方我主观上已经有了结果，但是光靠个人的感受，没有数据的支撑（延时抖动、丢包率、峰值宽带均值），直接写上去未免太不严谨，等我测全了，再一点点补上去也不迟。如果您喜欢这篇文章的话，也欢迎点赞啦，或许能成为我追更的动力哦。我会尽可能研究一些网上不曾有的ISP资料，并在此呈现给大家~如果有任何不正确的地方也请指正，我会尽快修改，非常感谢！参考资料https://github.com/sjlleo/local-ISPs-to-CN/blob/main/report_zh_CN.md

Kubernetes实战03：Container 6 Contrainer 特性6.1 容器生命周期Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的阶段一样。 你可以使用容器生命周期回调来在容器生命周期中的特定时间点触发事件。一旦调度器将 Pod 分派给某个节点，kubelet 就通过容器运行时开始为 Pod 创建容器。容器的状态有三种：Waiting（等待）、Running（运行中）和 Terminated（已终止）。要检查 Pod 中容器的状态，你可以使用 kubectl describe pod <pod 名称>。 其输出中包含 Pod 中每个容器的状态。每种状态都有特定的含义：Waiting （等待）如果容器并不处在 Running 或 Terminated 状态之一，它就处在 Waiting 状态。 处于 Waiting 状态的容器仍在运行它完成启动所需要的操作：例如， 从某个容器镜像仓库拉取容器镜像，或者向容器应用 Secret 数据等等。 当你使用 kubectl 来查询包含 Waiting 状态的容器的 Pod 时，你也会看到一个 Reason 字段，其中给出了容器处于等待状态的原因。Running（运行中）Running 状态表明容器正在执行状态并且没有问题发生。 如果配置了 postStart 回调，那么该回调已经执行且已完成。 如果你使用 kubectl 来查询包含 Running 状态的容器的 Pod 时， 你也会看到关于容器进入 Running 状态的信息。Terminated（已终止）处于 Terminated 状态的容器已经开始执行并且或者正常结束或者因为某些原因失败。 如果你使用 kubectl 来查询包含 Terminated 状态的容器的 Pod 时， 你会看到容器进入此状态的原因、退出代码以及容器执行期间的起止时间。如果容器配置了 preStop 回调，则该回调会在容器进入 Terminated 状态之前执行。6.2 容器生命周期回调/事件/钩子类似于许多具有生命周期回调组件的编程语言框架，例如 Angular、Vue、Kubernetes 为容器提供了生命周期回调。 回调使容器能够了解其管理生命周期中的事件，并在执行相应的生命周期回调时运行在处理程序中实现的代码。有两个回调暴露给容器：PostStart 这个回调在容器被创建之后立即被执行。 但是，不能保证回调会在容器入口点（ENTRYPOINT）之前执行。 没有参数传递给处理程序。PreStop 在容器因 API 请求或者管理事件（诸如存活态探针、启动探针失败、资源抢占、资源竞争等） 而被终止之前，此回调会被调用。 如果容器已经处于已终止或者已完成状态，则对 preStop 回调的调用将失败。 在用来停止容器的 TERM 信号被发出之前，回调必须执行结束。 Pod 的终止宽限周期在 PreStop 回调被执行之前即开始计数， 所以无论回调函数的执行结果如何，容器最终都会在 Pod 的终止宽限期内被终止。 没有参数会被传递给处理程序。使用容器生命周期回调# nginx-pod.yml apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx:1.19 lifecycle: postStart: #容器创建过程中执行 exec: command: ["/bin/sh","-c","echo postStart >> /start.txt"] preStop: #容器终止之前执行 exec: command: ["/bin/sh","-c","echo postStop >> /stop.txt && sleep 5"] ports: - containerPort: 806.3 容器重启策略Pod 的 spec 中包含一个 restartPolicy 字段，其可能取值包括 Always(总是重启)、OnFailure(容器异常退出状态码非 0,重启) 和 Never。默认值是 Always。restartPolicy 适用于 Pod 中的所有容器。restartPolicy 仅针对同一节点上 kubelet 的容器重启动作。当 Pod 中的容器退出时，kubelet 会按指数回退方式计算重启的延迟（10s、20s、40s、...），其最长延迟为 5 分钟。 一旦某容器执行了 10 分钟并且没有出现问题，kubelet 对该容器的重启回退计时器执行重置操作。apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx:1.19 imagePullPolicy: IfNotPresent restartPolicy: Always # OnFailure Never6.4 自定义容器启动命令和 Docker 容器一样,k8s中容器也可以通过command、args 用来修改容器启动默认执行命令以及传递相关参数。但一般推荐使用 command 修改启动命令，使用 args 为启动命令传递参数。apiVersion: v1 kind: Pod metadata: name: redis labels: app: redis spec: containers: - name: redis image: redis:5.0.10 command: ["redis-server"] #用来指定启动命令 args: ["--appendonly yes"] # 用来为启动命令传递参数 #args: ["redis-server","--appendonly yes"] # 单独使用修改启动命令并传递参数 #args: # 另一种语法格式 # - redis-server # - "--appendonly yes" imagePullPolicy: IfNotPresent restartPolicy: Always6.5 容器探针probe 是由 kubelet对容器执行的定期诊断。 要执行诊断，kubelet 既可以在容器内执行代码，也可以发出一个网络请求。定义: 容器探针 就是用来定期对容器进行健康检查的。探测类型针对运行中的容器，kubelet 可以选择是否执行以下三种探针，以及如何针对探测结果作出反应：livenessProbe 指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策略决定未来。如果容器不提供存活探针， 则默认状态为 Success。readinessProbe指示容器是否准备好为请求提供服。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针，则默认状态为 Success。startupProbe 1.7+指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器， 而容器依其重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。探针机制使用探针来检查容器有四种不同的方法。 每个探针都必须准确定义为这四种机制中的一种：exec在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。grpc使用 gRPC 执行一个远程过程调用。 目标应该实现 gRPC健康检查。 如果响应的状态是 "SERVING"，则认为诊断成功。 gRPC 探针是一个 Alpha 特性，只有在你启用了 "GRPCContainerProbe" 特性门控时才能使用。httpGet对容器的 IP 地址上指定端口和路径执行 HTTP GET 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。tcpSocket对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。 如果远程系统（容器）在打开连接后立即将其关闭，这算作是健康的。探针结果每次探测都将获得以下三种结果之一：Success（成功）容器通过了诊断。Failure（失败）容器未通过诊断。Unknown（未知）诊断失败，因此不会采取任何行动。探针参数initialDelaySeconds: 5 #初始化时间5s periodSeconds: 4 #检测间隔时间4s timeoutSeconds: 1 #默认检测超时时间为1s failureThreshold: 3 #默认失败次数为3次，达到3次后重启pod successThreshold: 1 #默认成功次数为1次，1次监测成功代表成功使用探针execapiVersion: v1 kind: Pod metadata: name: liveness-exec labels: exec: exec spec: containers: - name: nginx image: nginx:1.19 ports: - containerPort: 80 args: - /bin/sh - -c - sleep 7;nginx -g "daemon off;" #这一步会和初始化同时开始运行，也就是在初始化5s后和7秒之间，会检测出一次失败，7秒后启动后检测正常，所以pod不会重启 imagePullPolicy: IfNotPresent livenessProbe: exec: #这里使用 exec 执行 shell 命令检测容器状态 command: - ls - /var/run/nginx.pid #查看是否有pid文件 initialDelaySeconds: 5 #初始化时间5s periodSeconds: 4 #检测间隔时间4s timeoutSeconds: 1 #默认检测超时时间为1s failureThreshold: 3 #默认失败次数为3次，达到3次后重启pod successThreshold: 1 #默认成功次数为1次，1 次代表成功说明：1. 如果 sleep 7s，第一次检测发现失败，但是第二次检测发现成功后容器就一直处于健康状态不会重启。 1. 如果 sleep 30s，第一次检测失败，超过 3 次检测同样失败，k8s 就回杀死容器进行重启，反复循环这个过程。tcpSocketapiVersion: v1 kind: Pod metadata: name: liveness-tcpsocket labels: tcpsocket: tcpsocket spec: containers: - name: nginx image: nginx:1.19 ports: - containerPort: 80 args: - /bin/sh - -c - sleep 7;nginx -g "daemon off;" #这一步会和初始化同时开始运行，也就是在初始化5s后和7秒之间，会检测出一次失败，7秒后启动后检测正常，所以pod不会重启 imagePullPolicy: IfNotPresent livenessProbe: tcpSocket: port: 80 initialDelaySeconds: 5 #初始化时间5s periodSeconds: 4 #检测间隔时间4s timeoutSeconds: 1 #默认检测超时时间为1s failureThreshold: 3 #默认失败次数为3次，达到3次后重启pod successThreshold: 1 #默认成功次数为1次，1 次代表成功httpGet# probe-liveness-httget.yml apiVersion: v1 kind: Pod metadata: name: liveness-httpget labels: httpget: httpget spec: containers: - name: nginx image: nginx:1.19 ports: - containerPort: 80 args: - /bin/sh - -c - sleep 7;nginx -g "daemon off;" #这一步会和初始化同时开始运行，也就是在初始化5s后和7秒之间，会检测出一次失败，7秒后启动后检测正常，所以pod不会重启 imagePullPolicy: IfNotPresent livenessProbe: httpGet: #httpget port: 80 #访问的端口 path: /index.html #访问的路径 initialDelaySeconds: 5 #初始化时间5s periodSeconds: 4 #检测间隔时间4s timeoutSeconds: 1 #默认检测超时时间为1s failureThreshold: 3 #默认失败次数为3次，达到3次后重启pod successThreshold: 1 #默认成功次数为1次，1 次代表成功GRPC 探针官方参考地址: https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/6.6 资源限制在k8s中对于容器资源限制主要分为以下两类:内存资源限制: 内存请求（request）和内存限制（limit）分配给一个容器。 我们保障容器拥有它请求数量的内存，但不允许使用超过限制数量的内存。官网参考地址: https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/CPU 资源限制: 为容器设置 CPU request（请求） 和 CPU limit（限制）。 容器使用的 CPU 不能超过所配置的限制。 如果系统有空闲的 CPU 时间，则可以保证给容器分配其所请求数量的 CPU 资源。官网参考地址: https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/请求 request memory cpu :可以使用的基础资源 100M限制 limit memory cpu :可以使用的最大资源 200M 超过最大资源之后容器会被 kill , OOM 错误1 metrics-server官网地址: https://github.com/kubernetes-sigs/metrics-serverKubernetes Metrics Server (Kubernetes指标服务器)，它是一个可扩展的、高效的容器资源度量源。Metrics Server 用于监控每个 Node 和 Pod 的负载（用于Kubernetes内置自动扩缩管道）。Metrics Server 从Kubelets 收集资源指标，并通过 Metrics API 在Kubernetes apiserver中公开，供 Horizontal Pod Autoscaler 和 Vertical Pod Autoscaler 使用。Metrics API 也可以通过 kubectl top 访问，使其更容易调试自动扩缩管道。查看 metrics-server（或者其他资源指标 API metrics.k8s.io 服务提供者）是否正在运行， 请键入以下命令：kubectl get apiservices如果资源指标 API 可用，则会输出将包含一个对 metrics.k8s.io 的引用。NAME v1beta1.metrics.k8s.io安装 metrics-server# components.yaml apiVersion: v1 kind: ServiceAccount metadata: labels: k8s-app: metrics-server name: metrics-server namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: labels: k8s-app: metrics-server rbac.authorization.k8s.io/aggregate-to-admin: "true" rbac.authorization.k8s.io/aggregate-to-edit: "true" rbac.authorization.k8s.io/aggregate-to-view: "true" name: system:aggregated-metrics-reader rules: - apiGroups: - metrics.k8s.io resources: - pods - nodes verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: labels: k8s-app: metrics-server name: system:metrics-server rules: - apiGroups: - "" resources: - nodes/metrics verbs: - get - apiGroups: - "" resources: - pods - nodes verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: labels: k8s-app: metrics-server name: metrics-server-auth-reader namespace: kube-system roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: extension-apiserver-authentication-reader subjects: - kind: ServiceAccount name: metrics-server namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: labels: k8s-app: metrics-server name: metrics-server:system:auth-delegator roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:auth-delegator subjects: - kind: ServiceAccount name: metrics-server namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: labels: k8s-app: metrics-server name: system:metrics-server roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:metrics-server subjects: - kind: ServiceAccount name: metrics-server namespace: kube-system --- apiVersion: v1 kind: Service metadata: labels: k8s-app: metrics-server name: metrics-server namespace: kube-system spec: ports: - name: https port: 443 protocol: TCP targetPort: https selector: k8s-app: metrics-server --- apiVersion: apps/v1 kind: Deployment metadata: labels: k8s-app: metrics-server name: metrics-server namespace: kube-system spec: selector: matchLabels: k8s-app: metrics-server strategy: rollingUpdate: maxUnavailable: 0 template: metadata: labels: k8s-app: metrics-server spec: containers: - args: - --cert-dir=/tmp - --secure-port=4443 - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname - --kubelet-use-node-status-port - --metric-resolution=15s - --kubelet-insecure-tls #修改去掉证书验证 image: dyrnq/metrics-server:v0.6.2 #修改官方无法下载 imagePullPolicy: IfNotPresent livenessProbe: failureThreshold: 3 httpGet: path: /livez port: https scheme: HTTPS periodSeconds: 10 name: metrics-server ports: - containerPort: 4443 name: https protocol: TCP readinessProbe: failureThreshold: 3 httpGet: path: /readyz port: https scheme: HTTPS initialDelaySeconds: 20 periodSeconds: 10 resources: requests: cpu: 100m memory: 200Mi securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 1000 volumeMounts: - mountPath: /tmp name: tmp-dir hostNetwork: true #必须指定这个才行 nodeSelector: kubernetes.io/os: linux priorityClassName: system-cluster-critical serviceAccountName: metrics-server volumes: - emptyDir: {} name: tmp-dir --- apiVersion: apiregistration.k8s.io/v1 kind: APIService metadata: labels: k8s-app: metrics-server name: v1beta1.metrics.k8s.io spec: group: metrics.k8s.io groupPriorityMinimum: 100 insecureSkipTLSVerify: true service: name: metrics-server namespace: kube-system version: v1beta1 versionPriority: 100$ kubectl appply -f components.yaml2 指定内存请求和限制官网: https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/为容器指定内存请求，请在容器资源清单中包含 resources：requests 字段。 同理，要指定内存限制，请包含 resources：limits。# nginx-memory-demo.yaml #内存资源的基本单位是字节（byte）。你可以使用这些后缀之一，将内存表示为 纯整数或定点整数：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。 例如，下面是一些近似相同的值：128974848, 129e6, 129M, 123Mi apiVersion: v1 kind: Pod metadata: name: nginx-memory-demo spec: containers: - name: nginx-memory-demo image: nginx:1.19 resources: requests: memory: "100Mi" limits: memory: "200Mi"查看容器内存使用情况$ kubectl get pod nginx-memory-demo --output=yaml查看容器正在使用内存情况$ kubectl top pod nginx-memory-demo 内存请求和限制的目的通过为集群中运行的容器配置内存请求和限制，你可以有效利用集群节点上可用的内存资源。 通过将 Pod 的内存请求保持在较低水平，你可以更好地安排 Pod 调度。 通过让内存限制大于内存请求，你可以完成两件事：Pod 可以进行一些突发活动，从而更好的利用可用内存。Pod 在突发活动期间，可使用的内存被限制为合理的数量。没有指定内存限制如果你没有为一个容器指定内存限制，则自动遵循以下情况之一：容器可无限制地使用内存。容器可以使用其所在节点所有的可用内存， 进而可能导致该节点调用 OOM Killer。 此外，如果发生 OOM Kill，没有资源限制的容器将被杀掉的可行性更大。运行的容器所在命名空间有默认的内存限制，那么该容器会被自动分配默认限制。3 指定 CPU 请求和限制官网: https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/为容器指定 CPU 请求，请在容器资源清单中包含 resources: requests 字段。 要指定 CPU 限制，请包含 resources:limits。# nginx-cpu-demo.yaml #CPU 资源以 CPU 单位度量。小数值是可以使用的。一个请求 0.5 CPU 的容器保证会获得请求 1 个 CPU 的容器的 CPU 的一半。 你可以使用后缀 m 表示毫。例如 100m CPU、100 milliCPU 和 0.1 CPU 都相同。 CPU 请求只能使用绝对数量，而不是相对数量。0.1 在单核、双核或 48 核计算机上的 CPU 数量值是一样的。 apiVersion: v1 kind: Pod metadata: name: nginx-cpu-demo spec: containers: - name: nginx-cpu-demo image: nginx:1.19 resources: limits: cpu: "1" requests: cpu: "0.5"显示 pod 详细信息$ kubectl get pod nginx-cpu-demo --output=yaml 显示 pod 运行指标$ kubectl top pod nginx-cpu-demoCPU 请求和限制的初衷通过配置你的集群中运行的容器的 CPU 请求和限制，你可以有效利用集群上可用的 CPU 资源。 通过将 Pod CPU 请求保持在较低水平，可以使 Pod 更有机会被调度。 通过使 CPU 限制大于 CPU 请求，你可以完成两件事：Pod 可能会有突发性的活动，它可以利用碰巧可用的 CPU 资源。Pod 在突发负载期间可以使用的 CPU 资源数量仍被限制为合理的数量。如果不指定 CPU 限制如果你没有为容器指定 CPU 限制，则会发生以下情况之一：容器在可以使用的 CPU 资源上没有上限。因而可以使用所在节点上所有的可用 CPU 资源。容器在具有默认 CPU 限制的名字空间中运行，系统会自动为容器设置默认限制。如果你设置了 CPU 限制但未设置 CPU 请求​ 如果你为容器指定了 CPU 限制值但未为其设置 CPU 请求，Kubernetes 会自动为其 设置与 CPU 限制相同的 CPU 请求值。类似的，如果容器设置了内存限制值但未设置 内存请求值，Kubernetes 也会为其设置与内存限制值相同的内存请求。7 Pod 中 init 容器Init 容器是一种特殊容器，在Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。7.1 init 容器特点init 容器与普通的容器非常像，除了如下几点：它们总是运行到完成。如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。 然而，如果 Pod 对应的 restartPolicy 值为 "Never"，并且 Pod 的 Init 容器失败， 则 Kubernetes 会将整个 Pod 状态设置为失败。每个都必须在下一个启动之前成功完成。同时 Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe， 因为它们必须在 Pod 就绪之前运行完成。如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。 每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时， Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。Init 容器支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。 然而，Init 容器对资源请求和限制的处理稍有不同。7.2 使用 init 容器官网地址: https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/init-containers/在 Pod 的规约中与用来描述应用容器的 containers 数组平行的位置指定 Init 容器。apiVersion: v1 kind: Pod metadata: name: init-demo spec: containers: - name: myapp-container image: busybox:1.28 command: ['sh', '-c', 'echo The app is running! && sleep 3600'] initContainers: - name: init-myservice image: busybox:1.28 command: ['sh', '-c', 'echo init-myservice is running! && sleep 5'] - name: init-mydb image: busybox:1.28 command: ['sh', '-c', 'echo init-mydb is running! && sleep 10']查看启动详细$ kubectl describe pod init-demo # 部分结果 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m16s default-scheduler Successfully assigned default/init-demo to k8s-node2 Normal Pulling 2m16s kubelet Pulling image "busybox:1.28" Normal Pulled 118s kubelet Successfully pulled image "busybox:1.28" in 17.370617268s (17.370620685s including waiting) Normal Created 118s kubelet Created container init-myservice Normal Started 118s kubelet Started container init-myservice Normal Pulled 112s kubelet Container image "busybox:1.28" already present on machine Normal Created 112s kubelet Created container init-mydb Normal Started 112s kubelet Started container init-mydb Normal Pulled 101s kubelet Container image "busybox:1.28" already present on machine Normal Created 101s kubelet Created container myapp-container Normal Started 101s kubelet Started container myapp-container

Kubernetes实战02：Pod 第三章 Pod & Container什么是 PodPod 基本操作Pod 的 LabelsPod 的 生命周期Container 特性Pod 的资源限制Pod 中 Init 容器节点亲和性分配 Pod1 什么是 Pod摘取官网: https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/#working-with-pods1.1 简介Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。Pod（就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）容器； 这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。简言之如果用 Docker 的术语来描述，Pod 类似于共享名字空间并共享文件系统卷的一组容器。定义: Pod 就是用来管理一组(一个|多个)容器的集合 特点: 共享网络 共享存储 共享上下文环境1.2 Pod 怎样管理多个容器?Pod 中的容器被自动安排到集群中的同一物理机或虚拟机上，并可以一起进行调度。 容器之间可以共享资源和依赖、彼此通信、协调何时以及何种方式终止自身。例如，你可能有一个容器，为共享卷中的文件提供 Web 服务器支持，以及一个单独的 "边车 (sidercar)" 容器负责从远端更新这些文件，如下图所示：1.3 如何使用 Pod?通常你不需要直接创建 Pod，甚至单实例 Pod。 相反，你会使用诸如 Deployment 或 Job 这类工作负载资源来创建 Pod。 如果 Pod 需要跟踪状态，可以考虑 StatefulSet 资源。Kubernetes 集群中的 Pod 主要有两种用法：运行单个容器的 Pod。"每个 Pod 一个容器" 模型是最常见的 Kubernetes 用例； 在这种情况下，可以将 Pod 看作单个容器的包装器，并且 Kubernetes 直接管理 Pod，而不是容器。运行多个协同工作的容器 的 Pod。 Pod 可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。 这些位于同一位置的容器可能形成单个内聚的服务单元 —— 一个容器将文件从共享卷提供给公众， 而另一个单独的 “边车”（sidecar）容器则刷新或更新这些文件。 Pod 将这些容器和存储资源打包为一个可管理的实体。说明: 将多个并置、同管的容器组织到一个 Pod 中是一种相对高级的使用场景。 只有在一些场景中，容器之间紧密关联时你才应该使用这种模式。每个 Pod 都旨在运行给定应用程序的单个实例。如果希望横向扩展应用程序 （例如，运行多个实例以提供更多的资源），则应该使用多个 Pod，每个实例使用一个 Pod。 在 Kubernetes 中，这通常被称为副本（Replication）。 通常使用一种工作负载资源及其控制器来创建和管理一组 Pod 副本。2 Pod 基本操作2.1 查看 pod# 查看默认命名空间的 pod $ kubectl get pods|pod|po # 查看所有命名空间的 pod $ kubectl get pods|pod -A $ kubectl get pods|pod|po -n 命名空间名称 # 查看默认命名空间下 pod 的详细信息 $ kubectl get pods -o wide # 查看所有命名空间下 pod 的详细信息 $ kubectl get pods -o wide -A # 实时监控 pod 的状态 $ kubectl get pod -w2.2 创建 podpod : kubectl run nginx(pod名称) --image=nginx:1.19container: docker run --name nginx nginx:1.19官网参考地址: https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/# nginx-pod.yml apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx:1.19 ports: - containerPort: 80# 使用 kubectl apply/create -f 创建 pod $ kubectl create -f nginx-pod.yml $ kubectl apply -f nginx-pod.yml注意: create 仅仅是不存在时创建,如果已经存在则报错！apply 不存在创建，存在更新配置。推荐使用 apply！2.3 删除 pod$ kubectl delete pod pod名称 $ kubectl delete -f pod.yml2.4 进入 pod 中容器# 注意: 这种方式进入容器默认只会进入 pod 中第一个容器 $ kubectl exec -it nginx(pod名称) --(固定写死) bash(执行命令) # 注意: 进入指定 pod 中指定容器 $ kubectl exec -it pod名称 -c 容器名称 --(固定写死) bash(执行命令)2.5 查看 pod 日志# 注意: 查看 pod 中第一个容器日志 $ kubectl logs -f(可选,实时) nginx(pod 名称) # 注意: 查看 pod 中指定容器的日志 $ kubect logs -f pod名称 -c 容器名称2.6 查看 pod 描述信息$ kubectl describe pod nginx(pod名称)3 Pod 运行多个容器3.1 创建 pod# myapp-pod.yml apiVersion: v1 kind: Pod metadata: name: myapp spec: containers: - name: nginx image: nginx:1.19 ports: - containerPort: 80 imagePullPolicy: IfNotPresent - name: redis image: redis:5.0.10 ports: - containerPort: 6379 imagePullPolicy: IfNotPresent$ kubectl apply -f myapp-pod.yml3.2 查看指定容器日志# 查看日志 (默认只查看第一个容器日志，这里是展示 nginx 日志) $ kubectl logs -f myapp # 查看 pod 中指定容器的日志 $ kubectl logs -f myapp -c nginx(容器名称) $ kubectl logs -f myapp -c redis(容器名称)3.3 进入容器# 进入 pod 的容器 (默认进入第一个容器内部，这里会进入 nginx 容器内部) $ kubectl exec -it myapp -- sh # 进入 pod 中指定容器内部 $ kubectl exec -it myapp -c nginx -- sh $ kubectl exec -it myapp -c redis -- sh4 Pod 的 Labels(标签)标签（Labels） 是附加到 Kubernetes 对象（比如 Pod）上的键值对。 标签旨在用于指定对用户有意义且相关的对象的标识属性。标签可以在创建时附加到对象，随后可以随时添加和修改。每个对象都可以定义一组键(key)/值(value)标签，但是每个键(key)对于给定对象必须是唯一的。标签作用: 就是用来给 k8s 中对象起别名, 有了别名可以过滤和筛选4.1 语法标签由键值对组成，其有效标签值：必须为 63 个字符或更少（可以为空）除非标签值为空，必须以字母数字字符（[a-z0-9A-Z]）开头和结尾包含破折号（-）、下划线（_）、点（.）和字母或数字4.2 示例apiVersion: v1 kind: Pod metadata: name: myapp labels: name: myapp #创建时添加 spec: containers: - name: nginx image: nginx:1.21 imagePullPolicy: IfNotPresent - name: redis image: redis:5.0.10 imagePullPolicy: IfNotPresent restartPolicy: Always4.3 标签基本操作# 查看标签 $ kubectl get pods --show-labels # kubectl label pod pod名称 标签键值对 $ kubectl label pod myapp env=prod # 覆盖标签 --overwrite $ kubectl label --overwrite pod myapp env=test # 删除标签 -号代表删除标签 $ kubectl label pod myapp env- # 根据标签筛选 env=test/env > = < $ kubectl get po -l env=test $ kubectl get po -l env $ kubectl get po -l '!env' # 不包含的 pod $ kubectl get po -l 'env in (test,prod)' #选择含有指定值的 pod $ kubectl get po -l 'env notin (test,prod)' #选择含有指定值的 pod5 Pod 的生命周期摘自官网: https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/Pod 遵循预定义的生命周期，起始于 Pending 阶段， 如果至少其中有一个主要容器正常启动，则进入 Running，之后取决于 Pod 中是否有容器以失败状态结束而进入 Succeeded 或者 Failed 阶段。与此同时Pod 在其生命周期中只会被调度一次。 一旦 Pod 被调度（分派）到某个节点，Pod 会一直在该节点运行，直到 Pod 停止或者被终止。5.1 生命周期和一个个独立的应用容器一样，Pod 也被认为是相对临时性（而不是长期存在）的实体。 Pod 会被创建、赋予一个唯一的 ID(UID)， 并被调度到节点，并在终止（根据重启策略）或删除之前一直运行在该节点。如果一个节点死掉了，调度到该节点的 Pod 也被计划在给定超时期限结束后删除。Pod 自身不具有自愈能力。如果 Pod 被调度到某节点而该节点之后失效， Pod 会被删除；类似地，Pod 无法在因节点资源耗尽或者节点维护而被驱逐期间继续存活。 Kubernetes 使用一种高级抽象来管理这些相对而言可随时丢弃的 Pod 实例， 称作控制器。任何给定的 Pod （由 UID 定义）从不会被“重新调度（rescheduled）”到不同的节点； 相反，这一 Pod 可以被一个新的、几乎完全相同的 Pod 替换掉。 如果需要，新 Pod 的名字可以不变，但是其 UID 会不同。如果某物声称其生命期与某 Pod 相同，例如存储卷， 这就意味着该对象在此 Pod （UID 亦相同）存在期间也一直存在。 如果 Pod 因为任何原因被删除，甚至完全相同的替代 Pod 被创建时， 这个相关的对象（例如这里的卷）也会被删除并重建。5.2 pod 阶段Pod 阶段的数量和含义是严格定义的。 除了本文档中列举的内容外，不应该再假定 Pod 有其他的 phase 值。取值描述Pending（悬决）Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。Running（运行中）Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。Succeeded（成功）Pod 中的所有容器都已成功终止，并且不会再重启。Failed（失败）Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。Unknown（未知）因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。说明：当一个 Pod 被删除时，执行一些 kubectl 命令会展示这个 Pod 的状态为 Terminating（终止）。 这个 Terminating 状态并不是 Pod 阶段之一。 Pod 被赋予一个可以体面终止的期限，默认为 30 秒。 你可以使用 --force 参数来强制终止 Pod。如果某节点死掉或者与集群中其他节点失联，Kubernetes 会实施一种策略，将失去的节点上运行的所有 Pod 的 phase 设置为 Failed。

Kubernetes实战01：概念和安装 Kubernetes官网: https://kubernetes.io/zh-cn/第一章 初识 KubernetesKubernetes 简介为什么需要 KubernetesKubernetes 能做什么Kubernetes 不是什么?1 简介摘取官网: https://kubernetes.io/zh-cn/docs/concepts/overview/Kubernetes 这个名字源于希腊语，意为舵手或飞行员。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。 Google 在 2014 年开源了 Kubernetes 项目。 Kubernetes 建立在 Google 大规模运行生产工作负载十几年经验的基础上， 结合了社区中最优秀的想法和实践。Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态，其服务、支持和工具的使用范围相当广泛。从 2014 年第一个版本发布以来，Kuberetes 迅速获得开源社区的追捧，包括 Red Hat、VMware 在内的很多有影响力的公司加入到开发和推广的阵营。目前 Kubernetes 已经成为发展最快、市场占有率最高的容器编排引攀产品。2 为什么需要 k8s摘取官网: https://kubernetes.io/zh-cn/docs/concepts/overview/传统部署时代：早期，各个组织是在物理服务器上运行应用程序。由于无法限制在物理服务器中运行的应用程序资源使用，因此会导致资源分配问题。 例如，如果在同一台物理服务器上运行多个应用程序， 则可能会出现一个应用程序占用大部分资源的情况，而导致其他应用程序的性能下降。 一种解决方案是将每个应用程序都运行在不同的物理服务器上， 但是当某个应用程式资源利用率不高时，剩余资源无法被分配给其他应用程式， 而且维护许多物理服务器的成本很高。虚拟化部署时代：因此，虚拟化技术被引入了。虚拟化技术允许你在单个物理服务器的 CPU 上运行多台虚拟机（VM）。 虚拟化能使应用程序在不同 VM 之间被彼此隔离，且能提供一定程度的安全性， 因为一个应用程序的信息不能被另一应用程序随意访问。虚拟化技术能够更好地利用物理服务器的资源，并且因为可轻松地添加或更新应用程序， 而因此可以具有更高的可扩缩性，以及降低硬件成本等等的好处。 通过虚拟化，你可以将一组物理资源呈现为可丢弃的虚拟机集群。每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。容器部署时代：容器类似于 VM，但是更宽松的隔离特性，使容器之间可以共享操作系统（OS）。 因此，容器比起 VM 被认为是更轻量级的。且与 VM 类似，每个容器都具有自己的文件系统、CPU、内存、进程空间等。 由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。容器的出现解决了应用和基础环境异构的问题，让应用可以做到一次构建，多次部署。不可否认容器是打包和运行应用程序的好方式，因此容器方式部署变得流行起来。但随着容器部署流行，仅仅是基于容器的部署仍有一些问题没有解决:生产环境中， 你需要管理运行着应用程序的容器，并确保服务不会下线。 例如，如果一个容器发生故障，则你需要启动另一个容器。高并发时，你需要启动多个应用程序容器为系统提高高可用，并保证多个容器能负载均衡。在维护、升级版本时，你需要将运行应用程序容器从新部署，部署时必须对之前应用容器备份，一旦出现错误，需要手动启动之前容器保证系统运行。如果以上行为交由给系统处理，是不是会更容易一些？那么谁能做到这些?3 k8s 能做什么?摘取官网: https://kubernetes.io/zh-cn/docs/concepts/overview/这就是 Kubernetes 要来做的事情！ Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移你的应用、提供部署模式等。Kubernetes 为你提供：服务发现和负载均衡Kubernetes 可以使用 DNS 名称或自己的 IP 地址来暴露容器。 如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。存储编排Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。自动部署和回滚你可以使用 Kubernetes 描述已部署容器的所需状态， 它可以以受控的速率将实际状态更改为期望状态。 例如，你可以自动化 Kubernetes 来为你的部署创建新容器， 删除现有容器并将它们的所有资源用于新容器。自动完成装箱计算/自动资源调度你为 Kubernetes 提供许多节点组成的集群，在这个集群上运行容器化的任务。 你告诉 Kubernetes 每个容器需要多少 CPU 和内存 (RAM)。 Kubernetes 可以将这些容器按实际情况调度到你的节点上，以最佳方式利用你的资源。自我修复/自愈能力Kubernetes 将重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器， 并且在准备好服务之前不将其通告给客户端。密钥与配置管理Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。4 k8s 不是什么?Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。 由于 Kubernetes 是在容器级别运行，而非在硬件级别，它提供了 PaaS 产品共有的一些普遍适用的功能， 例如部署、扩展、负载均衡，允许用户集成他们的日志记录、监控和警报方案。 但是，Kubernetes 不是单体式（monolithic）系统，那些默认解决方案都是可选、可插拔的。 Kubernetes 为构建开发人员平台提供了基础，但是在重要的地方保留了用户选择权，能有更高的灵活性。Kubernetes：不限制支持的应用程序类型。 Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。 如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。不部署源代码，也不构建你的应用程序。 持续集成（CI）、交付和部署（CI/CD）工作流取决于组织的文化和偏好以及技术要求。不提供应用程序级别的服务作为内置服务，例如中间件（例如消息中间件）、 数据处理框架（例如 Spark）、数据库（例如 MySQL）、缓存、集群存储系统 （例如 Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制（例如开放服务代理）来访问。不是日志记录、监视或警报的解决方案。 它集成了一些功能作为概念证明，并提供了收集和导出指标的机制。不提供也不要求配置用的语言、系统（例如 jsonnet），它提供了声明性 API， 该声明性 API 可以由任意形式的声明性规范所构成。不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。 编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。 而 Kubernetes 包含了一组独立可组合的控制过程，可以连续地将当前状态驱动到所提供的预期状态。 你不需要在乎如何从 A 移动到 C，也不需要集中控制，这使得系统更易于使用且功能更强大、 系统更健壮，更为弹性和可扩展。第二章 组件&架构集群组件核心概念集群安装1 集群组件集群 cluster : 将同一个软件服务多个节点组织到一起共同为系统提供服务过程称之为该软件的集群。redis 集群、es集群、mongo 等。k8s 集群: 多个节点: 3 个节点 角色: 1.master 节点/control plane 控制节点 2. work node: 工作节点(pod 容器:应用程序容器)当部署完 Kubernetes，便拥有了一个完整的集群。一组工作机器，称为节点， 会运行容器化应用程序。每个集群至少有一个工作节点。工作节点会托管 Pod ，而 Pod 就是作为应用负载的组件。 控制平面管理集群中的工作节点和 Pod。1.1 控制平面组件（Control Plane Components）控制平面组件会为集群做出全局决策，比如资源的调度。 以及检测和响应集群事件，例如当不满足部署的 replicas 字段时， 要启动新的 pod）。控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。kube-apiserverAPI server是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API server 是 Kubernetes 控制平面的前端。Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。etcd一致且高度可用的键值存储，用作 Kubernetes 的所有集群数据的后台数据库。kube-schedulerkube-scheduler 是控制平面的组件， 负责监视新创建的、未指定运行节点 node 的 Pods， 并选择节点来让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。kube-controller-managerkube-controller-manager 是控制平面的组件， 负责运行控制器进程。从逻辑上讲， 每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。这些控制器包括：节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）。cloud-controller-manager (optional 可选)一个 Kubernetes 控制平面组件， 嵌入了特定于云平台的控制逻辑。 云控制器管理器（Cloud Controller Manager）允许你将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不需要有云控制器管理器。与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中， 供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。下面的控制器都包含对云平台驱动的依赖：节点控制器（Node Controller）：用于在节点终止响应后检查云提供商以确定节点是否已被删除路由控制器（Route Controller）：用于在底层云基础架构中设置路由服务控制器（Service Controller）：用于创建、更新和删除云提供商负载均衡器1.2 Node 组件节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行环境。kubeletkubelet 会在集群中每个节点（node）上运行。 它保证容器（containers）都运行在 Pods 中。kubelet 接收一组通过各类机制提供给它的 PodSpecs， 确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。kube-proxykube-proxy是集群中每个节点（node）上所运行的网络代理， 实现 Kubernetes 服务（Service）概念的一部分。kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。容器运行时（Container Runtime）容器运行环境是负责运行容器的软件。Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-0、Docker 以及 Kubernetes CRI 的其他任何实现。1.3 插件 (Addons)DNS尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该有集群 DNS因为很多示例都需要 DNS 服务。Web 界面（仪表盘）Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身， 并进行故障排除。容器资源监控容器资源监控将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中， 并提供浏览这些数据的界面。集群层面日志集群层面日志机制负责将容器的日志数据保存到一个集中的日志存储中， 这种集中日志存储提供搜索和浏览接口。2 集群架构详细总结Kubernetes 集群由多个节点组成，节点分为两类：一类是属于管理平面的主节点/控制节点（Master Node）；一类是属于运行平面的工作节点（Worker Node）。显然，复杂的工作肯定都交给控制节点去做了，工作节点负责提供稳定的操作接口和能力抽象即可。3 集群搭建[重点]minikube只是一个 K8S 集群模拟器，只有一个节点的集群，只为测试用，master 和 worker 都在一起。裸机安装至少需要两台机器（主节点、工作节点个一台），需要自己安装 Kubernetes 组件，配置会稍微麻烦点。缺点：配置麻烦，缺少生态支持，例如负载均衡器、云存储。直接用云平台 Kubernetes可视化搭建，只需简单几步就可以创建好一个集群。优点：安装简单，生态齐全，负载均衡器、存储等都给你配套好，简单操作就搞定k3s安装简单，脚本自动完成。优点：轻量级，配置要求低，安装简单，生态齐全。3.1 minikube3.2 裸机安装0 环境准备节点数量: 3 台虚拟机 centos7硬件配置: 2G或更多的RAM，2个CPU或更多的CPU，硬盘至少30G 以上网络要求: 多个节点之间网络互通，每个节点能访问外网1 集群规划k8s-node1：10.15.0.5k8s-node2：10.15.0.6k8s-node3：10.15.0.72 设置主机名$ hostnamectl set-hostname k8s-node1 $ hostnamectl set-hostname k8s-node2 $ hostnamectl set-hostname k8s-node33 同步 hosts 文件如果 DNS 不支持主机名称解析，还需要在每台机器的 /etc/hosts 文件中添加主机名和 IP 的对应关系：cat >> /etc/hosts <<EOF 10.15.0.5 k8s-node1 10.15.0.6 k8s-node2 10.15.0.7 k8s-node3 EOF4 关闭防火墙$ systemctl stop firewalld && systemctl disable firewalld5 关闭 SELINUX注意: ARM 架构请勿执行,执行会出现 ip 无法获取问题!$ setenforce 0 && sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config6 关闭 swap 分区$ swapoff -a && sed -ri 's/.*swap.*/#&/' /etc/fstab7 同步时间$ yum install ntpdate -y $ ntpdate time.windows.com8 安装 containerd# 安装 yum-config-manager 相关依赖 $ yum install -y yum-utils device-mapper-persistent-data lvm2 # 添加 containerd yum 源 $ yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo # 安装 containerd $ yum install -y containerd.io cri-tools # 配置 containerd $ cat > /etc/containerd/config.toml <<EOF disabled_plugins = ["restart"] [plugins.linux] shim_debug = true [plugins.cri.registry.mirrors."docker.io"] endpoint = ["https://frz7i079.mirror.aliyuncs.com"] [plugins.cri] sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.2" EOF # 启动 containerd 服务 并 开机配置自启动 $ systemctl enable containerd && systemctl start containerd && systemctl status containerd # 配置 containerd 配置 $ cat > /etc/modules-load.d/containerd.conf <<EOF overlay br_netfilter EOF # 配置 k8s 网络配置 $ cat > /etc/sysctl.d/k8s.conf <<EOF net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 net.ipv4.ip_forward = 1 EOF # 加载 overlay br_netfilter 模块 $ modprobe overlay $ modprobe br_netfilter # 查看当前配置是否生效 $ sysctl -p /etc/sysctl.d/k8s.conf9 添加源查看源$ yum repolist添加源 x86$ cat <<EOF > kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=0 repo_gpgcheck=0 gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg EOF $ mv kubernetes.repo /etc/yum.repos.d/添加源 ARM$ cat << EOF > kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-aarch64 enabled=1 gpgcheck=0 repo_gpgcheck=0 gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg EOF $ mv kubernetes.repo /etc/yum.repos.d/11 安装 k8s# 安装最新版本 $ yum install -y kubelet kubeadm kubectl # 指定版本安装 # yum install -y kubelet-1.26.0 kubectl-1.26.0 kubeadm-1.26.0 # 启动 kubelet $ sudo systemctl enable kubelet && sudo systemctl start kubelet && sudo systemctl status kubelet12 初始化集群注意: 初始化 k8s 集群仅仅需要再在 master 节点进行集群初始化!$ kubeadm init \ --apiserver-advertise-address=10.15.0.5 \ --pod-network-cidr=10.244.0.0/16 \ --image-repository registry.aliyuncs.com/google_containers \ --cri-socket=unix:///var/run/containerd/containerd.sock # 添加新节点 $ kubeadm token create --print-join-command --ttl=0 $ kubeadm join 10.15.0.21:6443 --token xjm7ts.gu3ojvta6se26q8i --discovery-token-ca-cert-hash sha256:14c8ac5c04ff9dda389e7c6c505728ac1293c6aed5978c3ea9c6953d4a79ed34 13 配置集群网络创建配置: kube-flannel.yml ,执行 kubectl apply -f kube-flannel.yml注意: 只在主节点执行即可!--- kind: Namespace apiVersion: v1 metadata: name: kube-flannel labels: pod-security.kubernetes.io/enforce: privileged --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: flannel rules: - apiGroups: - "" resources: - pods verbs: - get - apiGroups: - "" resources: - nodes verbs: - get - list - watch - apiGroups: - "" resources: - nodes/status verbs: - patch --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: flannel roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: flannel subjects: - kind: ServiceAccount name: flannel namespace: kube-flannel --- apiVersion: v1 kind: ServiceAccount metadata: name: flannel namespace: kube-flannel --- kind: ConfigMap apiVersion: v1 metadata: name: kube-flannel-cfg namespace: kube-flannel labels: tier: node app: flannel data: cni-conf.json: | { "name": "cbr0", "cniVersion": "0.3.1", "plugins": [ { "type": "flannel", "delegate": { "hairpinMode": true, "isDefaultGateway": true } }, { "type": "portmap", "capabilities": { "portMappings": true } } ] } net-conf.json: | { "Network": "10.244.0.0/16", "Backend": { "Type": "vxlan" } } --- apiVersion: apps/v1 kind: DaemonSet metadata: name: kube-flannel-ds namespace: kube-flannel labels: tier: node app: flannel spec: selector: matchLabels: app: flannel template: metadata: labels: tier: node app: flannel spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/os operator: In values: - linux hostNetwork: true priorityClassName: system-node-critical tolerations: - operator: Exists effect: NoSchedule serviceAccountName: flannel initContainers: - name: install-cni-plugin #image: flannelcni/flannel-cni-plugin:v1.1.0 for ppc64le and mips64le (dockerhub limitations may apply) image: docker.io/rancher/mirrored-flannelcni-flannel-cni-plugin:v1.1.0 command: - cp args: - -f - /flannel - /opt/cni/bin/flannel volumeMounts: - name: cni-plugin mountPath: /opt/cni/bin - name: install-cni #image: flannelcni/flannel:v0.20.2 for ppc64le and mips64le (dockerhub limitations may apply) image: docker.io/rancher/mirrored-flannelcni-flannel:v0.20.2 command: - cp args: - -f - /etc/kube-flannel/cni-conf.json - /etc/cni/net.d/10-flannel.conflist volumeMounts: - name: cni mountPath: /etc/cni/net.d - name: flannel-cfg mountPath: /etc/kube-flannel/ containers: - name: kube-flannel #image: flannelcni/flannel:v0.20.2 for ppc64le and mips64le (dockerhub limitations may apply) image: docker.io/rancher/mirrored-flannelcni-flannel:v0.20.2 command: - /opt/bin/flanneld args: - --ip-masq - --kube-subnet-mgr resources: requests: cpu: "100m" memory: "50Mi" limits: cpu: "100m" memory: "50Mi" securityContext: privileged: false capabilities: add: ["NET_ADMIN", "NET_RAW"] env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: EVENT_QUEUE_DEPTH value: "5000" volumeMounts: - name: run mountPath: /run/flannel - name: flannel-cfg mountPath: /etc/kube-flannel/ - name: xtables-lock mountPath: /run/xtables.lock volumes: - name: run hostPath: path: /run/flannel - name: cni-plugin hostPath: path: /opt/cni/bin - name: cni hostPath: path: /etc/cni/net.d - name: flannel-cfg configMap: name: kube-flannel-cfg - name: xtables-lock hostPath: path: /run/xtables.lock type: FileOrCreate14 查看集群状态# 查看集群节点状态 全部为 Ready 代表集群搭建成功 $ kubectl get nodes NAME STATUS ROLES AGE VERSION k8s-node1 Ready control-plane 21h v1.26.0 k8s-node2 Ready <none> 21h v1.26.0 k8s-node3 Ready <none> 21h v1.26.0 # 查看集群系统 pod 运行情况,下面所有 pod 状态为 Running 代表集群可用 $ kubectl get pod -A NAMESPACE NAME READY STATUS RESTARTS AGE default nginx 1/1 Running 0 21h kube-flannel kube-flannel-ds-gtq49 1/1 Running 0 21h kube-flannel kube-flannel-ds-qpdl6 1/1 Running 0 21h kube-flannel kube-flannel-ds-ttxjb 1/1 Running 0 21h kube-system coredns-5bbd96d687-p7q2x 1/1 Running 0 21h kube-system coredns-5bbd96d687-rzcnz 1/1 Running 0 21h kube-system etcd-k8s-node1 1/1 Running 0 21h kube-system kube-apiserver-k8s-node1 1/1 Running 0 21h kube-system kube-controller-manager-k8s-node1 1/1 Running 0 21h kube-system kube-proxy-mtsbp 1/1 Running 0 21h kube-system kube-proxy-v2jfs 1/1 Running 0 21h kube-system kube-proxy-x6vhn 1/1 Running 0 21h kube-system kube-scheduler-k8s-node1 1/1 Running 0 21h

计算机网络复习_传输层 概述传输层的功能提供进程和进程之间的逻辑通信复用和分用对收到的报文进行差错检测TCP和UDPTCP：面向连接的传输控制协议可靠，面向连接，时延大，适用于大文件UDP：无连接的用户数据报协议不可靠，无连接，时延小，使用于小文件分用和复用复用：应用层所有的应用进程都可以通过传输层在传输到网络层分用：传输层从网络层收到数据后交付指明的应用进程端口的长度为16bit，能表示65536个不同的端口号套接字Socket = (主机IP地址, 端口号)UDP主要特点：无连接，减少开销和发送数据之前的实验使用最大努力交付，即不保证可靠交付面向报文，适合一次性传输少量数据的网络应用无拥塞控制，适合很多实时应用首部开销少，只有 8 Byte，TCP 20 Byte首部格式：UDP校验：TCP特点：面向连接（虚连接）的传输层协议每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的TCP提供可靠可交付的服务，无差错、不丢失、不重复、按序到达。可靠有序，不丢不重提供全双工 -> 发送缓存 接收缓存面向字节流 -> 无结构的字节流首部格式：六个控制位窗口：指的是发送本报文段的一方的接收窗口，即现在允许对方发送的数据量检验和：检验首部+数据，检验时要加上12B胃受不，第四个字段为6紧急指针：URG=1时才有意义，指出本报文段中紧急数据的字节数选项：最大报文段长度MSS、窗口扩大、时间戳、选择确认...TCP连接管理三个阶段：连接建立->数据传送->连接释放连接建立：连接释放：可靠传输重传确认重传不分家，TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。->超时重传TCP采用自适应算法，动态改变重传时间RTTs(加权平均往返时间)冗余ACK：每当比期望序号大的时序报文段到达时，发送一个冗余ACK，指明下一个期待字节的序号 -> 快速重传流量控制TCP使用滑动窗口机制实现流量控制在通信过程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，即接收窗口rwnd（Receiver Window接收方设置确认报文段的窗口字段来将rwnd通知给发送方），发送方的发送窗口取接收窗口rwnd和拥塞窗口cwnd（Congestion Window）的最小值拥塞控制网络中有许多资源同时呈现供应不足->网络性能变差->网络吞吐量将随输入负荷增大而下降拥塞控制是全局性问题慢开始和拥塞避免快重传和快恢复