之前是要将应用迁移到k8s平台上面的时候，第一步做的就是应用容器化，做应用容器化的时候要对操作系统的一些资源做对接的时候所面临的挑战。
完成了容器化之后面临的挑战就是要将应用迁移到k8s平台，这个时候考虑的问题就更加多了。
下面就是如何将应用迁移到k8s平台上面去。
pod spec
在主应用拉起之前可能需要做一系列初始化的动作，应用和应用之间是互相通信是基于jwt token的，就是要获取token来证明我是谁，当a应用访问b应用的时候，a应用要带着它颁发好的token去访问b应用，然后b应用会去校验这个token是不是有效的token。token代表的应用是谁，它有没有这样的权限，这样就能够完成应用之间微服务调用的一个权限控制。
所以token是在应用启动的时候一次性获取的。这就是initcontainer来完成的工作，通过主container和init container之间共享同样的一个volume。
在定义容器的时候就需要去想有哪些初始化的动作是一次性的，之后就可以看是否可以将初始化动作一次性的放到initcontainer里面去。
初始化从container可以有很多，是一个list，自上而下顺序执行。
然后应用启动的时候要几个主container。
容器运行的时候需要什么权限，比如要去动操作系统上面的权限。还有可能去配置容器网络的权限。
一个pod内有多个容器，那么彼此之间要去做通信，天然网络的namespace就是共享的，容器a和容器b之间直接就可以进行网络调用，但是很多namespace是不共享的，比如pid，它们的进程彼此是隔离的，你要a容器里面进程去控制b容器里面的进程，那么就是要share pid。所以要去规划哪些namespace是需要共享的，这些都可以通过pod spec来控制。
应用代码和配置是要分离的，这个配置是从secret还是configmap来，这些配置信息拿到之后然后通过什么样的方式来挂到容器内部，通过环境变量还是文件方式让容器的进程可以消费。
服务部署在集群内部，是要给集群内部提供服务还是集群外部提供服务，是依赖于集群内部还是集群外部，如果对集群内部的服务没有诉求，那我我的dns policy就不需要设置为cluster first，就不需要去连接coredns，就不需要给它额外的压力，就可以设置为default，让它直接使用主机的配置去查询，这样减少对dns的压力。
镜像拉取的策略是什么？这些都要思考。