容器云在万达的落地

容器生态是现在非常火热的技术生态之一,个人认为它主要囊括着四个方面的技术栈:一是容器核心技术栈(包括 Docker、rkt 及第三方公司自主研发的容器 Engine 等);二是容器基础技术栈(包括容器网络、存储、安全及服务发现等);三是容器编排技术栈(包括 Mesos/Marathon、Swarm、Kubernetes 及 Openshift 等);四是容器应用技术栈(主要包括 CI/CD、监控、日志及微服务框架等)。而 Docker 和 Kubernetes 分别又是目前容器与容器编排界的小宠儿,所以我将带着小宠从这四方面分享一些容器云在万达的落地经验。

万达容器云平台支持快速部署、弹性伸缩、负载均衡、灰度发布、高效运维及微服务等特性。用户可以基于 Dashboard 简单方便地上线和管理着各自业务。目前在我们的容器云平台上,平稳高效运行着近 400 款包括支付、酒店等核心业务,管理着公司上万个容器。经历住了双旦、618 及双 11 等大型活动的考验。

我将从以下三个方面介绍万达容器云:

一、容器云的平台高可用架构与部署

二、容器云的技术架构介绍

三、容器云的填坑实践

一、容器云的平台高可用架构与部署

“经济基础决定上层建筑”,对于整个容器云平台来说,K8S 平台就是我们的“经济基础”,所以在建设之初我们为了保证平台的稳定、高可用还是做了不少工作。先来看看 K8S 平台的建设涉及到的几个技术点:

– 组件的高可用性如何保证?

– 组件以何种方式部署安装?

– 集群以何种方式快速扩缩容?

– 如何实现环境的批量配置及组件的批量升级?

为了较好的描述这些,我画了一张我们容器云中 K8S 各组件高可用架构与部署图,请见:

K8S 所有组件都容器化了,而不采用二进制安装的方式。这样对于组件的部署、配置更新和升级等都比较容易,只需要先安装好 Docker,提前做好镜像,然后直接 docker run –restart=always –name xxx_component xxx_component_image:xxx_version 就可以了,这里 –restart=always 非常重要,用来保证主机重启后或由于突发状况引起的非错误性退出后组件服务自动恢复。

注意在升级过程中,为了减少组件服务的宕机时间,需要提前下载好新制作的镜像版本,因为如果镜像挺大的话,在 docker restart 进行更新前会耗费一些时间在 docker pull 上面。

在批量部署方面,我们采用 Ansible 工具。由于 K8S 集群部署的文档网上蛮多的,所以这里就简要介绍一下组件的高可用部分。我们都知道 K8S 实现了应用的高可用,而针对 K8S 自身的 HA,主要还是在 Etcd 和 K8S Master 组件上面。

1、 Etcd 的高可用性部署

Etcd 使用的是 V3(3.0.3)的版本,比 V2 版本性能强很多。Etcd 组件作为一个高可用强一致性的服务发现存储仓库,它的 HA 体现在两方面:一方面是 Etcd 集群自身需要以集群方式部署,以实现 Etcd 数据存储的冗余、备份与高可用;另一方面是 Etcd 存储的数据需要考虑使用可靠的存储设备。

为了展示一下组件容器化在部署方面带来的一些便利效果,以 Etcd 的部署为例,先在 Ansible inventory 文件中规划好 Etcd 的分组信息,一般是采用 3 台做为集群即可。例如:

然后编写好类似如下的 template 文件,就可以用 Ansible Playbook 实现一键秒级的部署 Etcd 集群了,注意我这里使用了主机 IP 作为 Etcd 的名字。

如果需要升级则只需要修改一下 etcd_version 并提前拉取新版本镜像,重新跑一下 ansible-playbook –limit=etcds -i hosts/cd-prod k8s.yaml –tags etcd 即可完成秒级升级,这样一般显得简洁易用。当然 Etcd 在升级过程中还涉及到数据的迁移备份等,这个可以参考官方文档进行。

2、K8S Master 的高可用性部署

K8S 的版本我们更新的不频繁,目前使用的是 V1.6.6。Master 的三个组件是以 Static Pod 的形式启动并由 kubelet 进行监控和自动重启的,而 kubelet 自身也以容器的方式运行。

对于 kube-apiserver 的 HA,我们会配置一个 VIP,通过 haproxy 和 keepalived 来实现,其中 haproxy 用于负载均衡,而 keepalived 负责对 haproxy 做监控以保证它的高可用性。后面就可以通过 <VIP>:<Port> 来访问 apiserver。

对于 kube-controller-manager 和 kube-scheduler 的 HA,由于它们会修改集群的状态,所以对于这两个组件,高可用不仅要保证有多个实例,还需要保证在多个实例间实现 leader 的选举,因此在启动参数中需要分别设置 –leader-elect=true。

对于 K8S 集群的扩缩容,只需要采用 Ansible 进行批量操作或者 kubectl 命令(一般需要用到 drain, cordon , uncordon 等)完成即可。另外我们还需要注意一下图中标注的各组件启动时依赖的参数配置,这些比较容易搞混。

二、容器云的技术架构介绍

目前使用的容器云架构方案如图所示,我将其分为四个部分,每个部分包含对应的容器技术栈,下面对于主流的技术介绍如下:

1、存储方案:

后端存储主要采用 ceph 驱动,这里主要介绍它在有状态服务和 docker-registry 两方面的应用。

有状态是应用程序的高级需求,它们需要在 Pod 挂了特别是飘移到其他 Node 后,可以持续的访问后端存储。因此,K8S 通过网络存储提供了丰富的 Persistent Volume 支持,比如:GCE 的 pd,AWS 的 ebs,还有 GlusterFS,Ceph 等先进的分布式文件系统。我们目前使用了 Ceph 的 rbd 来支持有状态服务。K8S 集群环境中,由于所有的组件采用容器化部署,因此除了在主机上安装 ceph-common 之外,还需要在 kubelet、kube-controller-manager 容器中安装它,而且在启动时挂载如下三个 volume,其他的与二进制方式差不多:

具体 ceph rbd 配置,详见:Persistent Volume Provisioning 官网(https://github.com/kubernetes/examples/blob/master/staging/persistent-volume-provisioning/README.md

rbd 支持动态供应,支持单节点读写,多节点读,但不支持多节点写。如果有业务需要多节点写的话,rbd 就比较受限制。目前由于只有 GlusterFS 既允许动态供应,又支持单节点和多节点读写,所以我们也正在调研其相关使用。

docker-registry 做为容器的核心部分,起初我们采用 Swift 作为后端存储,为了提高 push/pull 的效率,采用 Redis 作为 Metadata 缓存,然后直接以容器的方式运行官方提供的镜像,比如:

具体的 config.yml 配置,详见:docker-registry 官方配置(https://github.com/docker/docker.github.io/blob/master/registry/deploying.md)。但后来为了保证 docker-registry 的高可用,我们采用 Harbor 做 HA,并以 pod 的形式运行在 K8S 集群上,镜像数据以及 Harbor-db 全部通过 Ceph 的 PV 来挂载,这样就保证在 Harbor 主机挂了或者 Pod 故障后,Harbor 也可以 HA 了,同时我们也不需要额外维护 Swift 了。

另外注意一个问题,由于 PV, StorageClass 都局限于单个 Namespace 下,所以对于想通过 Namespace 来区分多租户使用动态存储的情况目前是不满足的。

2、网络方案:

底层容器网络我们最初使用的是官方推荐的 Flannel,现在部分集群已经由 Flannel 切换成了 OVS 。 Flannel 可以很容易的实现 Pod 跨主机通信,但不能实现多租户隔离,也不能很好的限制 Pod 网络流量,所以我们网络同事开发了 K8S-OVS 组件来满足这些需求。它是一个使用 Open VSwitch 为 K8S 提供 SDN 功能的组件。该组件基于 Openshift SDN 的原理进行开发。由于 Openshift 的 SDN 网络方案和 Openshift 自身的代码耦合在一起,无法像 Flannel 和 Calico 等网络方案以插件的方式独立的为 K8S 提供服务,所以开发了 K8S-OVS 插件,它拥有 Openshift 优秀的 SDN 功能,又可以独立为 K8S 提供服务。

K8S-OVS 支持单租户模式和多租户模式,主要实现了如下功能:

– 单租户模式直接使用 Openvswitch+Vxlan 将 K8S 的 Pod 网络组成一个大二层,所有 Pod 可以互通。

– 多租户模式也使用 Openvswitch+Vxlan 来组建 K8S 的 Pod 网络,但是它可以基于 K8S 中的 Namespace 来分配虚拟网络从而形成一个网络独立的租户,一个 Namespace 中的 Pod 无法访问其他 Namespace 中的 Pod 和 Service。

– 多租户模式下可以对一些 Namespace 进行设置,使这些 Namespace 中的 Pod 可以和其他所有 Namespace 中的 Pods 和 Services 进行互访。

– 多租户模式下可以合并某两个 Namespace 的虚拟网络,让他们的 Pods 和 Services 可以互访。

– 多租户模式下也可以将上面合并的 Namespace 虚拟网络进行分离。

– 单租户和多租户模式下都支持 Pod 的流量限制功能,这样可以保证同一台主机上的 Pod 相对公平的分享网卡带宽,而不会出现一个 Pod 因为流量过大占满了网卡导致其他 Pod 无法正常工作的情况。

– 单租户和多租户模式下都支持外联负载均衡。

下面举例解释一下:

合并是指两个不同租户的网络变成一个虚拟网络从而使这两个租户中的所有 POD 和 SERVICE 能够互通;分离是指针对合并的两个租户,如果用户希望这两个租户不再互通了则可以将他们进行分离;全网化是指有一些特殊的服务需要能够和其他所有的租户互通,那么通过将这种特殊的租户进行全网化操作就可以实现。

不同租户的网络隔离是通过为每个 K8S 命名空间分配一个 VNI ( VXLAN 中的概念)来实现的,在 VXLAN 中不同的VNI可以隔离不同的网络空间。k8s-ovs 将具体的 K8S 命名空间和 VNI 的对应关系存储在 Etcd 中,如下:

这是在我们通过 K8S 创建 NAMESPACE 时,k8s-ovs 自动检测并为我们创建的。其中 NetName 是指租户的 K8S 命名空间;NetID 是指为该租户分配的VNI;Action 是指可以对该租户网络进行的操作,它包括 join :合并, isolate :分离, global :全网化,其中 join 需要指定上面的第四个参数 Namespace,用于表示需要和哪个租户进行合并,其他两个操作则不需要设置 Namespace。

合并之后观察 helloworld1 和 helloworld2 ,发现两个租户的 NetID 变为相同的了。这样两个网络的 POD 和 SERVICE 就可以相互访问了。

其他场景一样,通过 etcdctl update 来控制 Action 从而改变 NetID 来实现租户的隔离与互通。这里不过多演示。

在应用方面,我们实现了 LVS 的四层,Ingress(基于 Nginx+Ingress Controller) 的七层负载均衡,各 K8S 集群环境中陆续弃用了 K8S 自带的 kube-proxy 及 Service 方案。

3、CI/CD 方案:

CI/CD(持续集成与部署)模块肩负着 DevOps 的重任,是开发与运维人员的桥梁,它实现了业务(应用)从代码到服务的自动上线,满足了开发过程中一键的持续集成与部署的需求。

我们采用了前端基于 Opads(一个比较成熟的在线打包平台)和后端 Pluto(一个将 K8S apiserver 的接口进行封装,并提供 RestfulAPI 服务的库项目)的方案。目前通过该平台上线的业务有近 400 款。其架构图大致如下:

业务代码从公司内部的 Gitlab/Gerrit 中拉取后,用户选择不同的分支版本(比如:sit/uat/prod),经过 Jenkins 构建后,生成相应的镜像并 Push 到相应的镜像仓库中,底层 CD 模块从相应的仓库上线到相应的 K8S 集群 (sit/uat/prod) 中,而不需要 care 底层平台实现。

在整个 CI/CD 过程中,基础镜像的制作比较关键,我们按不同的业务分类提前制作不同的应用镜像(如:Tomcat、PHP、Java、NodeJS等)并打上所需的版本号,后面源代码既可以 mount 到相应的容器目录,也可以利用在 dockerfile 的 ONBUILD 命令完成业务代码的加载。挂载的方式优点是比较灵活,也不需要重复构建,上线效率高;缺点是对于基础镜像环境的依赖较高,如果一个业务的基础镜像一直未改动,但代码中又有了对新组件库的调用或者依赖,则很容易失败。onbuild 的方式和 mount 方式恰好相反,它每次都进行 build,解决了环境的依赖,后面版本回滚也方便,缺点是需要每次进行镜像构建,效率低。这些看业务自己的选择。

我们提供的基础镜像版本在业务上线的时候,业务开发者可以提前搜索确定基础镜像是否存在,如果不存在需要提 Jira 单子后,交由我们进行制作,部分截图如下:

之后,业务可以通过选择代码分支、版本等上线服务。之后就可以看到上线的业务详情了,包括 Pod 副本个数,存活时间,名字,创建时间,所在的 k8s 节点及 node selector 等。也可以通过基于 Gotty 实现的 Web console 登录查看业务容器,如图所示。

我们还实现了服务扩缩容,弹性伸缩(HPA)、负载均衡、灰度发布等,也加入了代码质量检查 (Sonar)、自动化测试及性能测试插件等,这些都是 CI/CD PAAS 平台的重要组成部分。

4、容器监控与告警方案:

容器监控的对象主要包括 K8S 集群(各组件)、应用服务、Pod、容器及网络等。这些对象主要表现为以下三个方面:

– K8S 集群自身健康状态监控 (5 个基础组件、Docker、Etcd、Flannel/OVS 等)

– 系统性能的监控,比如:cpu、内存、磁盘、网络、filesystem 及 processes 等;

– 业务资源状态监控,主要包括:rc/rs/deployment、Pod、Service 等;

K8S 组件相关的监控,我们写了相关的 shell 脚本,通过 crond 开启后监控各组件状态。

容器相关的监控,我们采用传统的 Heapster+Influxdb+Grafana 方案:

Heapster 首先从 K8S Master 获取集群中所有 Node 的信息,每个 Node 通过 kubelet 调用 cAdvisor API 来采集所有容器的数据信息(资源使用率和性能特征等)。这样既拿到了 Node 级别的资源使用状况信息,又拿到了容器级别的信息,它可以通过标签来分组这些信息,之后聚合所有监控数据,一起 sink 到 Heapster 配置的后端存储中(Influxdb),通过 Grafana 来支持数据的可视化。所以需要为 Heapster 设置几个重要的启动参数,一个是 –source 用来指定 Master 的 URL 作为数据来源,一个是 –sink 用来指定使用的后端存储系统(Influxdb),还有就是 –metric_resolution 来指定性能指标的精度,比如:30s 表示将过去 30 秒的数据进行聚合并存储。

这里说一下 Heapster 的后端存储,它有两个,一个是 metricSink,另一个是 influxdbSink。metricSink 是存放在本地内存中的 metrics 数据池,会默认创建,当集群比较大的时候,内存消耗会很大。Heapster API 获取到的数据都是从它那获取的。而 influxdbSink 接的是我们真正的数据存储后端,在新版本中支持多后端数据存储,比如可以指定多个不同的 influxDB 。

通过 Grafana, 用户可以使用各种正则表达式或者选项查看自己的业务监控详情,还可以按系统性能(cpu、内存、磁盘、网络、filesystem)进行排序查看等等。

当监控到一定的数量级,超过某个阈值时,将产生告警。虽然 Grafana 目前支持邮件进行一些简单的告警,但我们还是通过制定一些监控点、告警机制、告警等级等,然后接入公司内部现有 Zabbix 平台来进行告警。

邮件告警示例如下:

5、日志方案:

容器平台的日志系统一般包括:K8S 组件的日志,资源的事件日志及容器所运行的应用的日志。所以一个好的日志系统至少需要 cover 到这几块。

日志这块一直是我们头痛的地方,之前我们主要关心容器中的业务日志,所以是直接将其日志对接到公司的统一日志平台(Hippo)中。他们需要我们采用 Flume 来进行日志采集,每个业务以 Pod 的方式运行 Flume ,在 Flume 中配置好 source, channel 和 sink 参数。source 用来指定业务挂载的日志目录,然后通过 channel 进行输送,最后 sink 到后端的 Hippo 所使用的 Kafka 中。业务需要查看日志,则需要登录到 Hippo 平台中。

这个方案有一些不如意的地方,比如:每个业务需要单独额外运行一个 Flume 的 Pod,浪费资源;业务需要登录到另一个系统查看,由于不是对接到我们的平台中,不方便;另外由于 Hippo 是针对公司的统一的日志平台,不是容器云专用的,经常会在高峰期响应慢,很难处理过来。所以我们决定设计一个全新的平台,采用的方案是 K8S 官方推荐的(Fluentd+Kafka+ES+ 自定义界面),具体架构如下:

容器中输出的日志都会以 *-json.log 的命名方式保存在 /var/lib/docker/containers/ 中,系统日志都在 /var/log 中。Fluentd 以 Daemon Set 运行于所有的 Node 中进行数据采集,为了保证性能,引进了 Kafka 作为消息队列及日志转发,由于不想维护多个组件,中间转发不用 Logstash ,所以需要引入了两个 Fluentd 的插件 fluentd-kafka 及 fluentd-es,前者用于推送数据到 Kafka,后者用于将数据推到 ElasticSearch 中。

最后实现一个 Log API Engine 用于供上层 Log GUI 调用。这个 Engine 封装了实时日志、历史日志下载和查询、应用日志占比、日志等级占比等 Restful API。下面是我们的部分截图:

三、容器云的填坑实践

下面挑几个坑说一下,并分享一下解决方法。

Docker 相关:

早期由于混合使用了 Deployment 和 RC,此时如果使用了同名 Pod label 则会产生冲突,RC 会删除 Deployment 后创建的 Pod,造成 Pod 的反复创建与删除,最终导致 Node 上的 Docker daemon 挂僵掉。原因是 Docker device mapper 互锁而触发 Linux kernel bug(特别是有大量的 outbound traffic 时),解决方法是升级内核到 3.10.0-327.22.2,或者添加内核补丁(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a708cff93f1)

k8s 相关:

业务应用在升级过程中,如果 Docker 删除出错, 偶偶会导致 device mapper busy,则会显示 Pod 一直在销毁,但其实它的 Deployment 已经被删除了,这种我们没有找到很好的处理方法,现有 workaround 是先重启 docker daemon,如果不能解决,再 reboot 主机。一般的做法是先 drain 掉所有的 pod,然后待重启解决后,再 uncordon 回来。

在使用容器的方式部署 kubelet 时,我们发现删除 Pod 时,在 apiserver log 中一直会出现 UnmountVolume TearDown secrect 资源失败的错误。其中是当时在挂载 /var/lib/kubelet 时采用了 rw 的方式,这个问题困扰我们很久了,解决方法是加上 shared 即 –volume=/var/lib/kubelet:/var/lib/kubelet:rw,shared。

存储相关:

当某一 Pod 挂载 Ceph rbd 的 Volume 时,如果删除 Pod,再重新创建,由于 PVC 被 lock 导致无法挂载,会出现 volume 死锁问题。由于我们的 kubelet 是容器部署,而 ceph 组件是以挂载的方式开启的,所以猜测可能是由于 kubelet 容器部署引起,但后面改用二进制方式部署后也还是会出现 ceph lock。当时的版本是 V1.5.2,解决方法是升级到 V1.6.6 版本。

网络相关:

在业务上线过程中,一定要进行规范化约束,比如,当时将 Flannel 升级到 K8S-OVS 网络升级过程中出现有些业务采用 Service 进行负载均衡的情况,这种依赖于 kube-dns,由于 Flannel 和 OVS 的网段不一样,Service 层又没有打通,导致以 Service 运行并通过 kube-dns 解析时会出问题,且网络不通,本可以采用新建一个以 OVS 同网段的 kube-dns 来完成不同网段的兼容,但最后面发现该业务是根本不使用 Service,而是直接利用了 Pod,这样非规范化上线的业务很容易导致升级相关的故障出现,猜测可能当时平台建设初期手动上过业务,其实这方面我们也可以加些监控。

网络不稳定的时候,偶偶发现业务访问突然就慢起来了,然后发现其 TIME_WAIT 会出现过高,这个是没有对网络内核进行优化处理,此时需要设置 net.ipv4.tcp_tw_recycle = 1 和 net.ipv4.tcp_tw_reuse = 1 ,前者表示开启 TCP 连接中 TIME-WAIT Sockets 的快速回收,后者表示允许将 TIME-WAIT Sockets 重新用于新的 TCP 连接。当然还有其他网络内核优化。

告警相关:

CPU load 是通过每个核的 running queue(待运行进程队列)计算出来的,某些情况下 running queue 会变成 -1 也就是 4294967295。由于在 cpu 过载的时候,我们设置了告警,所以会被触发,但其实这时的 CPU 负载是正常的。此时,如果通过 sar -q ,top,w,uptime 等看到的 running queue 都是有问题后的值,只有用 vmstat 查看才是真实的。解决方法是重启 Node,因为这个值只有在重启后才会重置为零,或者升级内核补丁(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3d5f35bdfdef5fd627afe9b4bf9c4f32d17f4593)。

 

品类 – 商业思维


品类,不是商标法规定包装上的产品标准名称,也不是货架管理概念的产品类别划分,而是消费者认知上对产品的价值类别划分。

在货架管理者的概念里,洗发水都属同类产品,放在洗护类的产品区内,但在消费者心里,他们会认为,货架上的这些洗发水是不同的。海飞丝是去头屑的,飘柔是让头发更柔顺的,潘婷是让头发富有光泽的,霸王是中药防脱发的。

消费者一旦形成这样的价值划分,品类就建立起来了。驱动消费者做出选择和购买行为的,也正是这样的价值划分。

深陷产品海洋的消费者永远在用差异化价值导向的品类思维进行购买决策。高级别的营销做什么?就是做品类!

在饮料市场,六个核桃开创了益脑类功能营养品类,红牛开创了提神醒脑功能饮料品类,王老吉开创了预防上火的清凉饮料品类。

在家具建材市场,宜家开创了简装家具品类——风格简约、组装简单、价格亲民,索菲亚开创了定制家具品类。

在智能手机市场,苹果是科技美学的引领者,OPPO是针对自拍者的照相手机,而VIVO开创了音乐手机。

在中国牙膏市场,高露洁是防蛀虫的,黑人是美白牙齿的,冷酸灵防牙龈过敏,云南白药针对牙龈出血。

这些品牌,在各自的行业里找到了打开市场的正确方式,成为品类开创者和代表者,在消费者的心智领域成功圈出了一个专属领地。品类建立在消费者的大脑里。

品类战略简单而精准地描述为:推动产品在消费者心智中建立独特的价值类别认知,并成为该价值类别的代表。

品类是消费者在认知上对产品的价值类别划分。这个定义概念有两个关键词,一个是价值,一个是认知。

价值是什么?简单地说,价值就是能满足某种需求的有用东西,人是逐利性动物,能满足需求的,就有价值,不能满足需求的,就没有价值。价值因需求而产生,由“有用”或“无用”来判定。

荒漠求生中,一瓶水的价值可比生命,而一颗钻石的价值则趋零。

高蛋白好奶源的高端牛奶,在食品安全存在隐患的中国有存在价值,而在欧美、澳洲等食品安全不存在明显问题的国家,这个价值就没有存在的意义。

商业社会的游戏规则更是唯价值论的规则。产品能否与目标消费者进行关联,建立持久而稳固的关系,就在于产品是否具有满足目标群某种需求的价值,这是产品获取并黏合消费者最可靠的、最稳固的途径。

一切不以满足消费需求为出发点的产品都是臆想自嗨型的镜花水月。为什么每年新品失败率高达90%,其中有相当一部分属于价值指向不明的产品。

  • 99朵棉花织成的一双袜子,能满足什么需求?和消费者有什么关系?
  • 从竹根流淌出来的水,有什么独特价值?消费者为什么要选择喝你?
  • 清晨的第一杯水,随手可得那么多品牌的水,凭什么早上起来不喝别的就要喝你?
  • 喝了能添动力的功能饮料,在遍街都是功能饮料领导者红牛的天下,消费者为什么要放弃红牛转而选择你?

消费者以需求为动念,用品类来思考,构建品类价值,必须以消费者需求为着眼点

十年前,植物蛋白饮料被普遍当作区域性的风味饮料,既然是风味饮料,可喝可不喝,需求感不突出,价值感低,与消费者处于一种弱关系状态,这也是两大植物蛋白饮料始终做不大、做不强的重要原因之一。同时,风味饮料的地域性也限制了植物蛋白饮料成为主流饮料的可能性。如果六个核桃还是兜在风味饮料的小圈子里,过不了长江、10亿天花板到顶的经验预判将成事实。必须让六个核桃跳出风味饮料的圈子,重新开辟一个全新市场,才有机会打破禁锢。

人们都希望自己脑子好用,聪明,尤其在信息时代,从学校到职场,社会竞争就是脑力竞争,这是个烧脑、费脑的时代,人人唯恐脑不如人输掉机会。在这样的社会氛围下,脑力竞争的焦虑潜藏着人们希望增加脑营养、增强脑动力的巨大需求。

恰如二十世纪初的工业时代,美国人普遍被大机器生产带来的快节奏搞得神经质时,可口可乐以提神醒脑的价值迎合了神经衰弱的美国人振奋精神的需求,从亚特兰大的一个药房饮料卖到了全美。另一方面,富含磷脂、优质蛋白质的核桃已被现代科学实验证明有益大脑,在中国人的传统认知中,核桃也普遍被认为是有益大脑的坚果。但核桃坚果油脂过高,一次不宜多吃,吃起来也不方便,很多人也不喜欢核桃种皮的涩味。这造成了核桃是个好东西,但实际消费时机并不多的情况。

六个核桃改变了核桃的食用形式,以美味、可口的饮料化形式让人们能够更加便利化地摄取核桃营养。用美味、富含核桃营养的核桃乳来满足人们的益脑需求和愿望,塑造六个核桃有益大脑的营养饮料价值,开创益脑类功能营养饮料品类,以此把六个核桃从风味饮料的属地转移到益脑营养饮料的新领地。需求越强烈、越广谱,品类这把火越容易被点燃。

在消费需求的洞察上构建品类价值,尽可能地抢先抓大需求、强需求、稳需求。

价值之外,关于品类的定义概念中还有一个关键词,即认知。

在商业竞争社会,当消费者面临多得过剩的选择时,驱使其做出消费选择的就是脑子里的价值认知。

一瓶水在需求不同的人群里,也呈现出不同的价值认知。民工要的是便宜实在,中产要的是安全,霸道总裁要的是稀缺。这就是价值认知对消费行为的影响。

价值认知发生在大脑的思维活动里。我们说的心智定位就是要在目标消费者大脑里构建和占据一个满足其需求的产品或品牌的独特价值认知。一方面,需求产生了价值,另一方面,在消费者大脑中持续强化价值认知就是在不断地激发、巩固及强化需求,对需求起着巨大的反哺作用。

持续地提醒、强化消费者对产品的品类价值认知,就是在持续地刺激、强化消费者的产品需求,基于这种一个币的两面关系,构建品类价值认知、持续强化品类价值认知从本质上看,正对需求的一种有效管理。

需求的刺激和引导与认知的构建和强化同步,从而化为一种无意识的自觉行动。很多人吐槽脑白金的弱智广告,但一到过年过节想到要给长辈送心意,送礼就送脑白金,脑白金已深深地占据了年节长辈礼品的大脑档位。

因而,品类战略的实施内容,洞察需求、锁定价值只是万里长征的第一步,后面的万里之步就是通过持续不断的价值传播,为品类之火添柴加薪,巩固和保持目标消费者对品类价值的正确认知,保证品类价值认知不发生偏移、保证品类的价值认知免受不良影响、保证品类的价值认知能深深地扎根在消费者的大脑里,从而持久保证品类的被需要性。

注入品类价值符号,帮助消费者建立正确而清晰的品类价值认知

人类通过眼、耳、鼻、舌、身、意等六感体验来建立认知,形成概念。因此,被定位于益脑营养饮料,六个核桃就要围绕这个价值去塑造产品的六感体验,让消费者六感接收到的产品讯息都指向益脑价值,从而帮助品类快速、有效地嵌入消费者大脑里,形成正确、清晰的价值认知

作为信息传导的重要工具,语言是品类价值输出的尖刀,必须要锐利,直击潜在的消费需求点。尚扬设定的核心沟通语,通过“经常用脑”的典型场景画像,让目标群对号入座,感同身受,唤起他们对益脑的关注及需求,同时,将这个需求同六个核桃紧密关联起来,通过持续地反复传播,实现六个核桃与需求点的认知链接。引发需求、界定价值、与解决之道划等号,这就是六个核桃通过语言符号,对消费者意念产生的重大影响。

导入符号性的代言人在代言人的选择上,六个核桃选定时任凤凰卫视主播的鲁豫为六个核桃新的代言人,用睿智、知性的形象替代靓丽的代言人路线,鲁豫独特的大头形象从视觉及意念上强化了消费者对产品的价值认知印象。

升级包装,导入视觉符号生存期的六个核桃以露露为对标进行跟随,包装类杏仁露,导入品类战略后,六个核桃进行了包装的视觉升级,让包装也成为一种重要的品类识别。蓝色作为理性、科技与智慧的象征色,六个核桃在包装视觉上对其进行了优化表现,同时,导入核桃流乳的视觉符号,让消费者产生真材实料的品质联想,为品类价值进行信任背书。

随着市场拓进及升级,十年时间,六个核桃进行了四次包装的视觉体验优化,保持品类及品牌的活跃势能。2017年初,六个核桃导入“博士帽”的视觉概念,让六个核桃益脑的品类价值认知在视觉体验上得以强化和夯实。

聚焦符号人群及符号场景的品类价值宣导作为重要的信息输出渠道,在高空电视广告的大众传播上,典型人群及典型场景的消费引导策略,卡位重度用脑的符号性人群——学生进行产品消费示范,卡位“辛苦复习,紧张考试”的符号性用脑场景,进行品类价值宣导及消费引导。

打造符号性的宣导季及销售季,强化品类价值宣导

2012年,六个核桃导入高考季战略,将每年3-6月的高考季打造为六个核桃专属的品类宣导季,“这段时间特别用脑,多喝六个核桃”,锚定全国千万高考学生市场展开宣导及销售攻势,通过符号性时机强化了品类价值宣导,更将植物蛋白饮料的淡季转化春节、中秋等大销售节点之外的销售小节点,保持了品类全年销售的节奏。2017年,配合博士帽视觉符号,尚扬在高考季推出“冲刺梦想校园,多喝六个核桃”传播主题,为全国考生加油,持续深化高考季传播,强化品类与符号人群的黏合度。

升级价值背书,防御潜在威胁,确保品类良性发育,健康发展

在品类的成长过程中,随着品类市场的扩大,品类畅销全国,品类的代表品牌成为了公众品牌,将面临更广泛的消费者,层次及认知更为复杂,同时,也面临来自竞争对手各方面的挑战,为防止“千里之堤,溃于蚁穴”,确保品类安全发展的防御战略成为该阶段品类战略的重要内容。十年品类战略历程中,六个核桃不断升级品类的价值背书,一方面增强目标群的品类价值消费信心,夯实品类价值,另一方面防御树大招风效应,为品类健康良性的安全发展扫清隐患。

升级第三方权威机构的价值信任状品类导入期,在衡水地区相关机构展开核桃有益大脑的科学实验并获得报告证书。品类发展期,六个核桃与更高级别的权威机构——中国人民解放军军事医学科学院合作,就“核桃对脑发育及认知功能的改善作用及相关机制”展开研究,经过三年临床研究2015年获得最终报告,用科学实验证实了核桃的健脑功效

创作《信任状篇》的CF广告,在传播制高点央视《焦点访谈》的黄金广告位进行发布,宣告“研究表明,六个核桃有益大脑”,夯实品类价值,增强消费者对品类的价值信心。

用品质背书增强品类价值信任状

真材实料的品质是六个核桃有益大脑品类价值依托的根基,在夯实品类价值、确保品类安全发展的防御阶段,六个核桃展示真材实料的品质,将持续增强消费者对品类价值的信心。

2016年初,75秒长版本广告《核桃变身之旅》,展示树上核桃如何通过六个核桃的“5.3.28”工艺变身为一罐罐六个核桃,以领先的工艺技术树立了六个核桃的专业地位。

同年,辗转新疆、云南、太行山三地,在六个核桃核桃原料基地拍摄六个核桃收获核桃的微记录片,让广大消费者看见六个核桃真材实料的品质。

领先的工艺技术及真材实料的原料成为六个核桃高品质的两大核心支撑,成为六个核桃有益大脑品类价值的又一个强有力的信任状背书。

公益营销构筑品类战略的第三极

竞争战略之父迈克尔.波特在《企业慈善事业的竞争优势》淡到,“企业从事公益事业的目标,从表面看是为了博得更多的认同和社会影响,实质上,则更专注与企业竞争力的增强”,在西方,企业的公益成绩已经成为社会对企业进行业绩评估的一项重要指标。

科特勒在其著作《营销3.0》中也提出了营销将进入更高级的人文价值时代,卓越的品牌将更关注人类精神层面的需求。

六个核桃跨入百亿级品牌阵营,也将运用更高级的营销段位,为品类及品牌的健康发展创造具有深远价值的势能。

为此,2014年提出了《六个核桃公益营销报告》,构筑品类战略的第三极,将社会公益活动纳入六个核桃品类战略范畴,聚焦益脑品类价值,构建六个核桃“推动中国人阅读”的公益模式,提出“阅读,增长智慧,改变命运”的主题,形成六个核桃可持续性的公益战略行为。

2015年,“六个核桃.读书慧”公益活动全面启动,第一季为期三年至2018年,每年一千万、三年捐赠三千万用于为贫困地区学校购买图书。

开启六个核桃城市化战略,持续注入品类及品牌势能,保持品类及品牌活力

六个核桃走的是从农村到城市的发展路径,做透广大三、四线市场后,再往上进军一线市场。占据一线中心城市,才能成为真正的主流品类及一线领航品牌。

六个核桃提出的城市化战略构想目的在于推动六个核桃从春节、中秋节点箱货向日常箱货的延伸,从节庆礼品到日常生活自用。

让每个智娱秀场都成为六个核桃的品类价值示范秀场

在城市化战略构想下,除了推出城市化产品外(说明:尚处于商业保密阶段,尚扬暂不详解)六个核桃对影响大众品类价值认知的方式进行了战略性调整,与央视及各大卫视顶级智娱性节目深度合作,从单纯的高空硬广推广扩展为品类价值在节目中的深度植入。

六个核桃连续三年冠名了江苏卫视《最强大脑》、央视一套《挑战不可能》、《机智过人》、央视综合频道《加油向未来》、东方卫视《今晚80后脱口秀》、《诗书中华》湖北卫视《天才想得到》、湖南卫视《学霸天团》等等强势智娱节目。

提出“让每个智娱秀场都成为六个核桃益脑品类价值示范秀场”的指导思想,通过节目口播、场景设置等将六个核桃的品类价值与节目内容有机关联起来,实现资源的最大化效用。

这种更加时尚、生动的软传播方式在持续巩固及深化消费者的品类价值认知同时,也为六个核桃品牌注入了活力、时尚、时代元素,保持了品类及品牌的高势能状态。

升级品牌“顺”文化的价值传播

节庆礼品箱货是六个核桃的重要销售模式,益脑品类价值的注入,为礼品箱货赋予了根基性的价值内涵,避免潮流化、风尚化的危险,在礼品箱货市场释放出了巨量威力。

另一方面,中国节庆文化,让节庆消费带有浓郁的象征意义,节庆产品具有另一重情感价值,为此,2013年,尚扬为六个核桃导入“顺”文化的品牌情感价值,持续传播“六个核桃,六六大顺”,形成六个核桃独特的品类价值为根,文化价值为脉的双价值驱动链。

六个核桃十年品类战略历程所做关键动作,看起来碎片、散点、繁多,但每一个动作皆按照唯一的指向发生,即如何让益脑营养饮料的品类价值在消费者大脑里牢固地根植下来,这是六个核桃十年时间轴上品类发展的内在逻辑。从局部微观看,所有的动作是并不惊人的碎片和散点,但从全局宏观看,它们却构成了决定六个核桃核桃成功的聚焦、持续的战略执行系统。
任何一个战略最终都要靠人来实施。六个核桃品类战略的成功,不仅仅是重新定义品类价值的成功,也是六个核桃对品类战略实施到位的成功。它来自于两个方面,首先是企业决策者的战略素养,在没有现成市场、没有参照对标的情况下,决策者对战略具有敏锐的判断力、果断的决策力和无所畏惧的勇气。

此后,每一次的重大提案,皆是决议快、执行快,六个核桃领导者的高战略素养确保了其品类战略能够得以很好实施的可行性。

另一方面,养元憨严文化培养出了执行力和行动力超强的营销铁军,确保了品类战略能贯彻到传播、销售中,确保每一个实施动作准确到位。

波特认为战略的核心是创造差异化价值,而战略的放大器是协调性,这个协调性指的不仅仅是价值链内部各环节活动的相互联系,也是实现价值的营销、生产、技术、客服等组织内部在一致目标下的高效、协同工作,对战略效果起着放大作用。

品类战略是万里长征,因此,很多时候,不是战略制定得不对,而是执行不当,这是六个核桃十年品类历程赫然证明的一个真理。所以,有了品类战略的构想还远远不够,还需要企业对战略的真正领悟和理解,从而展开持续、系统、聚焦的战略动作。