Kubernetes 1.7 has an alpha feature called initializers. CoreOS has the concept of an operator. Both seem to involve deploying code that watches the Kubernetes API server for changes to resources—possibly custom—in the cluster, based on annotations those resources contain and which the code understands.
What's the difference? If initializers are part of the core platform, why would I need to create something new that does what looks to my eyes like the same thing?
Operators are standalone "microservices" continuously and asynchronously reconciling the configured desired state towards the system's current state. Initializers are synchronous hooks validating or mutating runtime objects before they are created or updated. Also see admission controllers. They are usually baked into some "microservice". When you consider the lifecycle of a runtime object then initializers are first to act, like once. Then operators watching runtime objects reconcile the system upon their desired definitions.
Kubernetes had the concept of initializers way before 1.7, but then they were a fixed part of the API server. The new initializers feature that you linked to is mainly a decoupling of those parts from the API server:
Today each of these plugins must be compiled into Kubernetes. As Kubernetes grows, the requirement that all policy enforcement beyond coarse grained access control be done through in-tree compilation and distribution becomes unwieldy and limits administrators and the growth of the ecosystem.
(from the design document)