典型的产品生命周期一般可分为四个阶段，即投入期、成长期、饱和期和衰退期

1.投入期。新产品投入市场，便进入投入期。此时，顾客对产品还不了解，只有少数追求新奇的顾客可能购买，销售量很低。为了扩展销路，需要大量的促销费用，对产品进行宣传。在这一阶段，由于技术方面的原因，产品不能大批量生产，因而成本高，销售额增长缓慢，企业不但得不到利润，反而可能亏损。产品也有待进一步完善。

2.成长期。这时顾客对产品已经熟悉，大量的新顾客开始购买，市场逐步扩大。产品大批量生产，生产成本相对降低，企业的销售额迅速上升，利润也迅速增长。竞争者看到有利可图，将纷纷进入市场参与竞争，使同类产品供给量增加，价格随之下降，企业利润增长速度逐步减慢，最后达到生命周期利润的最高点。

3.饱和期。市场需求趋向饱和，潜在的顾客已经很少，销售额增长缓慢直至转而下降，标志着产品进入了成熟期。在这一阶段，竞争逐渐加剧，产品售价降低，促销费用增加，企业利润下降。

4.衰退期。随着科学技术的发展，新产品或新的代用品出现，将使顾客的消费习惯发生改变，转向其他产品，从而使原来产品的销售额和利润额迅速下降。于是，产品又进入了衰退期。

引言
SpringIoc容器管理的Bean默认都是单例设计模式的，即每个Bean只有一个实例化的Bean对象存在于SpringIoc容器中，因此SpringIoc容器需要负责管理Bean的生命周期。
分类
Bean 的生命周期可以分为以下四类，

（1）Bean 的自身方法

（2）Bean生命周期接口方法

（3）容器级生命周期接口方法

（4）工厂后处理器接口方法




Spring生命周期各个阶段
相关接口及方法




Bean 的自身方法
Bean本身业务的方法。 配置文件中init-method和destroy-method指定的方法


Bean生命周期接口方法
InitializingBean接口，DiposiableBean接口，BeanNameAware接口 ，ApplicationContextAware接口，BeanFactoryAware接口等等


容器级生命周期接口方法
InstantiationAwareBeanPostProcessor接口实现，BeanPostProcessor接口实现


工厂后处理器接口方法
AspectJWWeavingEnabler ConfigurationClassPostProcessor,CustomAutowireConfigurer等


Bean 的自身方法及Bean生命周期接口方法
设计一个BeanLifeCycle类，继承相关接口
package com.Bean生命周期;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanNameAware;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

/**
 * Author:haozhixin
 * Func: Bean的生命周期
 * Date: 2019-08-05
 */
public class BeanLifeCycle implements BeanNameAware,ApplicationContextAware,InitializingBean,DisposableBean{
	/*
	* 构造器
	*
	*/
	public BeanLifeCycle(){
		System.out.println("1.[Bean级别]构造器执行了");
	}
	/*
	* BeanNameAware接口方法实现
	*
	*/
	@Override
	public void setBeanName(String name){
		System.out.println("2.[Bean级别]setBean方法执行了]");
	}

	/*
	* ApplicationContextAware接口方法实现
	*
	*/
	@Override
	public void setApplicationContext(ApplicationContext applicationContext) throws BeansException{
		System.out.println("3.[Bean级别]setApplicationContext方法执行了]");
	}
	/*
	* InitializingBean接口方法实现
	*
	*/
	@Override
	public  void afterPropertiesSet() throws  Exception{
		System.out.println("4.[Bean级别]afterPropertiesSet方法执行了]");
	}
	/*
	* init-method属性指定的方法
	*
	*/
	public void lifeCycleInit(){
		System.out.println("5.[Bean级别]lifeCycleInit方法执行了]");
	}
	/*
	* bean中的业务方法
	*
	*/
	public void sayHello(){
		System.out.println("6.[Bean级别]syHello方法执行了]");
	}
	/*
	* DisposableBean接口方法实现
	*
	*/
	@Override
	public void destroy() throws Exception {
		System.out.println("7.[Bean级别]destroy方法执行了]");
	}
	/*
	* destroy-method属性指定的方法
	*
	*/
	public void lifeCycleInitDestroy(){
		System.out.println("8.[Bean级别]lifeCycleInitDestroy方法执行了]");
	}
}


bean_life_cycle.xml配置方法
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

    <bean id="BeanLifeCycle" class="com.Bean生命周期.BeanLifeCycle" scope="singleton" init-method="lifeCycleInit" destroy-method="lifeCycleInitDestroy">

    </bean>
</beans>

测试类的写法
import com.Bean生命周期.BeanLifeCycle;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

/**
 * Author:haozhixin
 * Func: Bean的生命周期
 * Date: 2019-08-05
 */
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("classpath:bean_life_cycle.xml")
public class BeanLifeCycleTest {
	@Autowired
	private BeanLifeCycle beanLifeCycle;
	@Test
	public void test(){
		beanLifeCycle.sayHello();
	}
}


测试结果：
1.[Bean级别]构造器执行了
2.[Bean级别]setBean方法执行了]
3.[Bean级别]setApplicationContext方法执行了]
4.[Bean级别]afterPropertiesSet方法执行了]
5.[Bean级别]lifeCycleInit方法执行了]
6.[Bean级别]syHello方法执行了]
7.[Bean级别]destroy方法执行了]
8.[Bean级别]lifeCycleInitDestroy方法执行了]

我们可以看到执行顺序，即Bean自身方法和Bean声明周期接口方法生命周期为：

Ioc容器–>Bean构造器->BeanNameAware->ApplicationContextAware–>InitializingBean->init-method->Bean中的业务方法->DisposableBean->destroy-method方法。
容器级生命周期接口方法的执行次序
容器级接口方法一般有InstantiationAwareBeanPostProcessor和BeanPostProcessor两个接口，一般也将其实现类称为后处理器。容器级生命周期接口的实现独立于SpringIoc容器中的Bean，其是以容器拓展的形式注册到Spring中的。无论SpringIoc管理任何的Bean，这些后处理器都会发生作用。因此后处理器的影响范围是全局的SpringIoc容器中的Bean。用户可以通过编写合理的后处理器来实现自己对Bean的加工逻辑。

BeanPostProcessor：可以对Bean的属性进行更改
InstantiationAwareBeanPostProcessor：此接口可以在bean的实例化之前，之后操作，也可以在实例化之后进行属性操作
InstantiationAwareBeanPostProcessorAdapter：适配器类

代码实现：
package com.Bean生命周期;

import org.springframework.beans.BeansException;
import org.springframework.beans.PropertyValues;
import org.springframework.beans.factory.config.InstantiationAwareBeanPostProcessorAdapter;

import java.beans.PropertyDescriptor;

/**
 * Author:haozhixin
 * Func:
 * Date:
 */
public class ContainerLifeCycle extends InstantiationAwareBeanPostProcessorAdapter{
	/***
	 * 构造器
	 */
	public ContainerLifeCycle(){
		System.out.println("a.[容器级别]ContainerLifeCycle构造器执行了");
	}

	/***
	 *接口方法和实例化bean之前调用
	 */
	@Override
	public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
		System.out.println("b.[容器级别]postProcessBeforeInstantiation执行了,beanClass:"+beanClass);
		return null;
	}

    /***
     *设置某个属性时调用
     */
	@Override
	public PropertyValues postProcessPropertyValues(PropertyValues pvs, PropertyDescriptor[] pds, Object bean, String beanName) throws BeansException {
		System.out.println("c.[容器级别]postProcessPropertyValues执行了,beanName:"+beanName);
		return pvs;
	}


	/***
	 *接口方法和实例化Bean之后调用
	 */
	@Override
	public boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException {
		System.out.println("d.[容器级别]postProcessAfterInstantiation执行了,beanClass:"+bean.getClass());
		return true;
	}


}


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

    <bean id="ContainerLifeCycle" class="com.Bean生命周期.ContainerLifeCycle" scope="singleton" >

    </bean>
</beans>


import com.Bean生命周期.BeanLifeCycle;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

/**
 * Author:haozhixin
 * Func: Bean的生命周期
 * Date: 2019-08-05
 */
public class ContainerLifeCycleTest {
	public static void main(String [] args){
		ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("classpath:bean_life_cycle.xml","classpath:container_life_cycle.xml");
		BeanLifeCycle beanLifeCycle = context.getBean("BeanLifeCycle",BeanLifeCycle.class);
		beanLifeCycle.sayHello();
		context.close();
	}
}


运行结果：
a.[容器级别]ContainerLifeCycle构造器执行了
b.[容器级别]postProcessBeforeInstantiation执行了,beanClass:class com.Bean生命周期.BeanLifeCycle
1.[Bean级别]构造器执行了
d.[容器级别]postProcessAfterInstantiation执行了,beanClass:class com.Bean生命周期.BeanLifeCycle
c.[容器级别]postProcessPropertyValues执行了,beanName:BeanLifeCycle
2.[Bean级别]setBean方法执行了]
3.[Bean级别]setApplicationContext方法执行了]
4.[Bean级别]afterPropertiesSet方法执行了]
5.[Bean级别]lifeCycleInit方法执行了]
6.[Bean级别]syHello方法执行了]
7.[Bean级别]destroy方法执行了]
8.[Bean级别]lifeCycleInitDestroy方法执行了]

工厂级生命周期接口代码实现
话不多说，直接上代码
package com.Bean生命周期;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanNameAware;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.beans.factory.config.BeanFactoryPostProcessor;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

/**
 * Author:haozhixin
 * Func: Bean的生命周期
 * Date: 2019-08-05
 */
public class FactoryLifeCycle implements BeanFactoryPostProcessor{
	/*
	* 构造器
	*
	*/
	public FactoryLifeCycle(){
		System.out.println("一.[工厂级别]构造器执行了");
	}

	@Override
	public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
		System.out.println("二.[工厂级别]postProcessBeanFactory方法执行了");
	}
}


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

    <bean id="FactoryLifeCycle" class="com.Bean生命周期.FactoryLifeCycle" scope="singleton" >

    </bean>
</beans>

import com.Bean生命周期.BeanLifeCycle;
import org.springframework.context.support.ClassPathXmlApplicationContext;

/**
 * Author:haozhixin
 * Func: Bean的生命周期（工厂级别，bean级别，容器级别）
 * Date: 2019-08-05
 */
public class FactoryLifeCycleTest {
	public static void main(String [] args){
		ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("classpath:bean_life_cycle.xml","classpath:container_life_cycle.xml","classpath:factory_life_cycle.xml");
		BeanLifeCycle beanLifeCycle = context.getBean("BeanLifeCycle",BeanLifeCycle.class);
		beanLifeCycle.sayHello();
		context.close();
	}
}


执行结果是：
一.[工厂级别]构造器执行了
二.[工厂级别]postProcessBeanFactory方法执行了
a.[容器级别]ContainerLifeCycle构造器执行了
b.[容器级别]postProcessBeforeInstantiation执行了,beanClass:class com.Bean生命周期.BeanLifeCycle
1.[Bean级别]构造器执行了
d.[容器级别]postProcessAfterInstantiation执行了,beanClass:class com.Bean生命周期.BeanLifeCycle
c.[容器级别]postProcessPropertyValues执行了,beanName:BeanLifeCycle
2.[Bean级别]setBean方法执行了]
3.[Bean级别]setApplicationContext方法执行了]
4.[Bean级别]afterPropertiesSet方法执行了]
5.[Bean级别]lifeCycleInit方法执行了]
6.[Bean级别]syHello方法执行了]
7.[Bean级别]destroy方法执行了]
8.[Bean级别]lifeCycleInitDestroy方法执行了]

好了，就这么多，大家如果有疑问可以去Spring5企业级开发实战（五）下载以下源代码。

作者：select you from me

来源：CSDN

转载请联系作者获得授权并注明出处。

                    

前1/3篇幅分析企业生命周期，把企业生命周期分为：孕育期、婴儿期、学步期、青春期、壮年期、贵族期、官僚期，分别论述每个时期的特点，还有点意思。
后面尝试用四个参数PEAI（分别代表短期效益、短期效率、长期效益、长期效率）的强弱来描绘企业各个生命周期的特征，感觉不够有新意，字面上好像是没有其他人提过，但是基本的思想是很多人说过的。另外这四个参数的含义非常不好记，书中也没给出各个字母的含义的由来，看起来比较累。
排版有点乱，有些地方应该左对齐的变成居中了。
以下是书中一些信息的摘抄，#号后面是kindle电子书中的页码：
1：处于婴儿期的公司要做的是销售、销售，再销售。销售之所以如此重要，是因为如果不能收回资金，新创办的年轻公司将无法活下去。即使如此，我依然发现许多处于婴儿期的公司不善于销售。#821
2：处于婴儿期的公司有以下特点：●以行动为导向，受机会驱动。●几乎没有任何制度、规章、政策。●行为前后不一致。●问题无法得到及时解决而演变为危机，导致公司总是在处理一个又一个危机，这使它们变得十分脆弱。●领导者事必躬亲，不愿意授权给他人。●创始人的承诺不断被考验，而创始人的承诺对公司的生存十分关键。#873
3：婴儿期公司常常抱怨资金不足，但在它们努力获得资金的过程中，常常会犯一些基本的错误。●借入短期货款，但在长期内才能产生效益。●通过打折来促进销售，以获取资金，但经常发生的情况是，折扣太大，以至于销售收入包不住变动成本。●向风险投资人出售股权，但这些风险投资人并不与创始人拥有共同的愿景或利益。#898
4：许多咨询师、观察家批评婴儿期配偶的领导者，说他们不放权、工作太拼命、过于固执己见，他们的配偶也会这么说，但是只是因为自己创建了公司，他们才有了这些行为特征。#989
5：为什么处于婴儿期的公司需要专制型领导，还有一个原因，那就是危机管理。由于婴儿期公司在努力着生存下去，所以它们不能延误任何决策。#996
6：有些处于学步期的公司成了小型的集团公司，这是致命性的问题。它们参与很多相干的和不相干的业务。#1129
7：别指望学步期的领导者会去参加什么会议，他们很少参加，即使参加的话，他们也会把控会议的进程，而且其他人就再也没有机会说任何有实质性内容的话了。#1189
8：让员工崩溃的另一个因素是创始人的时间观念。在估计完成一件工作所需要的时间方面，学步期领导者的能力是极其不靠谱的。#1206
9：更糟糕的是，处于学步期公司的领导者，大部分都无法清晰地陈述他们的想法，员工在听了之后常常会感到莫名其妙：“他到底想要我去做什么？”#1212
10：学步期公司围绕人而不是围绕任务来进行组织管理。它们的发展是没有计划的，它们总是对出现的机会做出回应，而不是预先做好计划、组织并确定好自己的定位，以便利用好自己创造的未来机会，它们不去控制环境[34]，而是任由环境来控制它们。#1296
11：而对于学步期公司来说，如果不能开发出自己的管理体系，并使领导力制度化，它就会陷入创始人陷阱。#1329
12：什么是海鸥综合征？创始人在婴儿期和学步期那种掌控一切、事事亲力亲为的热情，现在（学步期）已经变成阻碍公司继续成长和发展的阻碍。创始人本人也深有挫败感。#1376
13：你是否注意到学步期复杂的情况了？创始人期盼能摆脱日常管理工作，但是他们又不打算放弃控制。他们一方面逐渐抽离，另一方面又难以放权，这就造成了一种遥控现象，而这或许是最糟糕的局面。创始人离开了，但是其他人都没有权力、没有胆量、没有勇气做出决策。#1388
14：由于没有正式的运转良好的控制制度，学步期公司的领导者只能依靠流言以及随机的信息来进行管理。尽管公司里充满了相互怀疑的气氛，但这些充满激情的企业家不满足于已有的成就，依然想大干一番。#1432
15：可以通过以下方面来识别一家公司是否处于青春期。●我们和他们——“旧时期的老人和新时代的新人”思维方式。●目标多变。●薪酬和激励制度多变。#1557
16：为什么从学步期到青春期的转变如此困难？因为这个转变面临三个主要的挑战：●授权。●领导的改变。●目标的转换。#1561
17：处于壮年早期的公司具有以下特点：●有清晰的愿景和价值观——“言必行”。●制度化的管理流程。●有控制和被鼓励的创造力。●综合性目标。●知轻重，分缓急。●运转良好的制度和组织结构●可预期的卓越表现。●销售额和边际利润双增长。●繁殖力强。●内外的凝聚力、整合力强。#1869
18：壮年期公司喜欢重复成功的气氛。具有自我约束力的管理层甚至会把坏的结果也看成成功，因为事情或许不能做得更好了，并且公司已经有了切实可行的计划来应对这种局面，而这才是最重要的。#2213
19：在壮年期之后，财务和法律部门获得了职权和权力，而责任却依然在营销和销售部门身上，这使得职权与责任分离开来。#2448
20：等到公司已经衰退的时候，它的行政管理体系、政策、先例、规章和方针等左右着它的行为。无论管理层如何努力以显现出是他们在进行控制，但决定公司行为的却是以往的决策和奖励制度。#2477
21：对于一家处于衰退中的公司来说，找那些不愿冒失去客户风险的咨询师来帮忙是错误的，这些咨询师所能起到的最好作用也就是缓解某些症状。衰退阶段的公司所需要的是某个能改变其权力结构的人，我把这种人叫作冒犯者，他们属于那种不怕引起疼痛和失去生意的咨询师。#2554
22：处于贵族期的公司有以下特点：●发展的欲望降低了。●对于征服新市场、新技术和开辟新领域兴趣不大。●重视过去的成就，而不是未来的发展前景。●对变化产生了怀疑情绪。●奖励顺从者、让干什么就干什么的人……#2759
23：贵族期公司所设计的会议室通常都会让人惊讶于它的与众不同。在一个典型的会议室里，几乎可以肯定你会看到一张巨大的、闪闪发光的黑色木质桌子，围着一圈与之配套的豪华椅子。#2794
24：等公司到了贵族期，形式压倒了功能，仅仅是它那空荡荡的走廊就足以满足好几个婴儿期公司的需要。总裁套房的租金——具有私人浴室、餐厅和秘书办公室——可能就会超过在学步期时公司为所有设施所付的租金。#2816
25：正常情况下，贵族期公司会去购买学步期的公司。对于贵族期公司来说，在一个正在增长的市场上，学步期公司及其新技术很有吸引力；而对于学步期公司来说，它们对靠自己努力走上正轨并实现发展感到厌倦，因此更容易接受大公司的收购请求。#2914
26：在贵族期晚期，公司的产品线已变得落伍，顾客知道这一点，销售人员知道这一点，甚至首席执行官也知道这一点。但是，没有人针对这个问题做些什么，人们不停地发出抱怨，而管理层则没完没了地开着那些毫无结果的会议。一句话，每个人都在等待别人去做些什么。#2940
27：处于官僚早期的公司，在行为上有以下特点：●人们关注的是谁导致了问题的产生，而不是关注应该对问题做些什么。会司变得对人不对事……。#3019
28：官僚期公司的特点如下：●制度繁多，但很少是为了提高工作效率。●与环境脱节，它关心的是自己。●缺少控制意识。●顾客不得不想出各种办法来绕过制度构成的阻碍。#3070
29：官僚期的公司是支离破碎的。没有任何一个人了解公司应当做的全部事情，每个人都只知道一小部分必要的信息，而客户必须自己把分离的信息归纳到一起。#3094
30：壮年期是分权的最佳时机。对学步期公司来说，因为还没有建立健全的控制系统和表述清晰的公司使命，分权可能很危险，甚至会导致失去控制的灾难。#5726
























本文转自左其盛博客园博客，原文链接：  http://www.cnblogs.com/zuoqs/p/7716405.html  ，如需转载请自行联系原作者



        
        
                
    

一、pod的生命周期
Pod 是 kubernetes 系统的基础单元，是由用户创建或部署的最小组件，也是 kubernetes 系统上运行容器化应用的资源对象

pod可以包含多个容器，应用运行在这些容器里面，同时pod也可以有一个或多个先于应用容器启动的init容器。、
二、init容器介绍
Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
Init 容器与普通的容器非常像，除了如下三点：
它们总是运行到完成。
Init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成。
每个 Init 容器必须运行成功，下一个才能够运行。

如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。
Init 容器作用
Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。

Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。

应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。

Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。

由于 Init 容器必须在应用容器启动之前运行完成，因此 Init
容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。


init容器实验
[root@server1 manifest]# vim init.yaml
[root@server1 manifest]# cat init.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
    - name: myapp-container
      image: myapp:v1
  initContainers:
    - name: init-container
      image: busybox
      command: ["/bin/sh", "-c", "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]

 

其中init容器种执行的命令是用来检测default 命名空间的解析，这个解析需要一个service，即init容器在运行时会检测service，若果service没有运行的话就会一直处于初始化状态。
我们先来运行一下这个pod：
[root@server1 manifest]# kubectl create -f init.yaml 
pod/myapp-pod created
[root@server1 manifest]# kubectl get pod
NAME        READY   STATUS     RESTARTS   AGE
myapp-pod   0/1     Init:0/1   0          83s

   

可以看出pod一直处于初始化状态。
现在进入容器内部查看解析：
[root@server1 manifest]# kubectl exec -it myapp-pod -c init-container -- sh
/ # nslookup myservice.default.svc.cluster.local
Server:		10.96.0.10
Address:	10.96.0.10:53

** server can't find myservice.default.svc.cluster.local: NXDOMAIN

^C
/ # 

可以看出果然没有解析。
接下来我们创建一个service：
[root@server1 manifest]# vim service.yaml 
[root@server1 manifest]# cat service.yaml 
kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

[root@server1 manifest]# kubectl create -f service.yaml 
service/myservice created
[root@server1 manifest]# kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP   2d4h
myservice    ClusterIP   10.109.148.189   <none>        80/TCP    9s

创建service成功，之后再查看pod状态：
[root@server1 manifest]# kubectl get pod -o wide
NAME        READY   STATUS    RESTARTS   AGE   IP            NODE      NOMINATED NODE   READINESS GATES
myapp-pod   1/1     Running   0          53s   10.244.2.18   server3   <none>           <none>

可以看出已经处于运行状态，同样我们可以访问它：

[
root@server1 manifest]# curl 10.244.2.18
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

之后再进入容器查看解析：
[root@server1 manifest]# kubectl run test -it  --image=radial/busyboxplus
If you don't see a command prompt, try pressing enter.
/ # nslookup myservice.default.svc.cluster.local
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      myservice.default.svc.cluster.local
Address 1: 10.109.148.189 myservice.default.svc.cluster.local
/ # 

果然解析成功。
因此可以验证如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。
实验完成后删除：
[root@server1 manifest]# kubectl delete pod test
[root@server1 manifest]# kubectl delete pod myapp-pod 
[root@server1 manifest]# kubectl delete svc myservice

三、探针
理解探针
容器探针用来检测主容器的运行状态。
在pod生命周期中可以做的一些事情。主容器启动前可以完成初始化容器，初始化容器可以有多个，他们是串行执行的，执行完成后就退出了，在主程序刚刚启动的时候可以指定一个post start 主程序启动开始后执行一些操作，在主程序结束前可以指定一个 pre stop 表示主程序结束前执行的一些操作。在程序启动后可以做两类常用检测 liveness probe（存活性探测） 和 readness probe（就绪性探测）
探针是由 kubelet 对容器执⾏的定期诊断。 要执⾏诊断， kubelet 调⽤由容器实现的 Handler。
有三种类型的探测方式：
ExecAction： 在容器内执⾏指定命令。 如果命令退出时返回码为 0 则认为诊断成功。
TCPSocketAction： 对指定端⼝上的容器的 IP 地址进⾏ TCP 检查。 如果端⼝打开， 则诊断被认为是成功的
HTTPGetAction： 对指定的端⼝和路径上的容器的 IP 地址执⾏ HTTP Get 请求。 如果响应的状态码⼤于等于200且⼩于400， 则诊断被认为是成功的。

每次探测都将获得以下三种结果之一
：
成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动。

Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出反应：
livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。
readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。
startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。

重启策略
PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。
livenessProbe存活探测示例
编辑以下yaml文件：
[root@server1 manifest]# vim liveness.yaml
[root@server1 manifest]# cat liveness.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: liveness-http
spec:
  containers:
    - name: myapp
      image: ikubernetes/myapp:v1
      imagePullPolicy: IfNotPresent
      livenessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 1
        periodSeconds: 3
        timeoutSeconds: 1

以上使用tcpsock检测容器8080端口，若liveness探针没有检测到8080端口则判定为不存活。由于我们运行的容器只暴露出来80端口，因此会检测失败。其中：
initialDelaySeconds: 1表示pod运行1s后检测状态。

periodSeconds: 3表示每3s检测一次。

timeoutSeconds: 1表示检测1s后即超时进行下次检测

之后运行并查看状态：
[root@server1 manifest]# kubectl create -f liveness.yaml 
pod/liveness-http created
[root@server1 manifest]# kubectl get pod
NAME            READY   STATUS    RESTARTS   AGE
liveness-http   1/1     Running   0          10s
[root@server1 manifest]# kubectl get pod
NAME            READY   STATUS             RESTARTS   AGE
liveness-http   0/1     CrashLoopBackOff   2          51s
[root@server1 manifest]# kubectl get pod
NAME            READY   STATUS    RESTARTS   AGE
liveness-http   1/1     Running   3          54s
[root@server1 manifest]# kubectl get pod
NAME            READY   STATUS    RESTARTS   AGE
liveness-http   1/1     Running   3          56s
[root@server1 manifest]# kubectl get pod
NAME            READY   STATUS    RESTARTS   AGE
liveness-http   1/1     Running   3          61s

可以看出检测失败一直在重启。
接下来我们将检测端口改为80端口再运行：
[root@server1 manifest]# kubectl delete -f liveness.yaml 

[root@server1 manifest]# vim liveness.yaml
[root@server1 manifest]# cat liveness.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: liveness-http
spec:
  containers:
    - name: myapp
      image: ikubernetes/myapp:v1
      imagePullPolicy: IfNotPresent
      livenessProbe:
        tcpSocket:
          port: 80
        initialDelaySeconds: 1
        periodSeconds: 3
        timeoutSeconds: 1

[root@server1 manifest]# kubectl create -f liveness.yaml 
pod/liveness-http created
[root@server1 manifest]# kubectl get pod
NAME            READY   STATUS    RESTARTS   AGE
liveness-http   1/1     Running   0          23s

可以看出启动成功，在运行状态。
实验后删除：
[root@server1 manifest]# kubectl delete -f liveness.yaml 

    

readinessProbe就绪检测示例：
编辑测试文件：
[root@server1 manifest]# vim reainess.yaml 
[root@server1 manifest]# cat reainess.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: readiness-http
spec:
  containers:
    - name: readiness
      image: nginx
      readinessProbe:
        httpGet:
          path: /test.html
          port: 80
        initialDelaySeconds: 1
        periodSeconds: 3
        timeoutSeconds: 1

以上使用httpGet的方式使用readinessProbe进行探测，表示在容器运行后检测test.html发布文件内容，若返回200到400之间的状态码则检测通过为READY状态，其他为不通过。
运行pod，并查看状态：
[root@server1 manifest]# kubectl create -f reainess.yaml 
pod/readiness-http created
[root@server1 manifest]# kubectl get pod
NAME             READY   STATUS    RESTARTS   AGE
readiness-http   0/1     Running   0          51s
[root@server1 manifest]# kubectl get pod
NAME             READY   STATUS    RESTARTS   AGE
readiness-http   0/1     Running   0          60s

可以看出是运行状态但是并不是READY状态，可以看出检测没有通过。
 [root@server1 manifest]# kubectl describe pod readiness-http

查看日志：
[root@server1 manifest]# kubectl logs readiness-http



此时我们进入容器添加test.html发布文件：
[root@server1 manifest]# kubectl exec -it readiness-http -- sh
# echo redhat > /usr/share/nginx/html/test.html
# 

查看pod状态：
[root@server1 manifest]# kubectl get pod
NAME             READY   STATUS    RESTARTS   AGE
readiness-http   1/1     Running   0          2m37s

可以看出已经是READY状态了。
可以看出就绪探针的作用了，即指示容器是否准备好服务请求。
实验后删除：
[root@server1 manifest]# kubectl delete -f reainess.yaml