The way I understand it, Plan9 provides the basics, so you can delegate to external nodes over 9P. But it doesn't provide an orchestration solution, so the answer would be "HA Plan 9 deployment" is not a thing - you'd need an extra layer.
Unless I missed something while researching P9 years ago.
A HA k8s- (or Heroku)- esque platform is more easily built, understood, and operated with Plan 9 because it comes out of the box with many of Docker (and Swarm's?) features.
The main argument is it comes with primitives that makes most of the orchestration systems' features redundant, because all the components of regular applications can just interoperate over a single unified messaging protocol and API. To consume some custom service, you just read/write a file. To expose a custom service, you just create a fileserver. To do wacky networking, you create a union of files. No more masses of abstractions and glue to tie pieces together because they all speak the same language.
In terms of HA, the implementation will be up to your preferred architecture (master/slave, master/master, p2p). Plan9 doesn't schedule services itself, so systemd would need to be modified to adapt one of those architectures. But it wouldn't be a whole lot of work, and it could reuse Plan9's abstractions for most of it. Etcd's key/value store becomes just a filesystem, and Paxos/Raft could be implemented either as a network driver or a userland app, which combined with a union fs, means you just manipulate a single directory of files. You don't even need to futz around with TLS, and again: filesystem permissions.
It's not a 1/1 replacement for K8s, but I bet about 80% of the codebase would go away, and most (if not all) of the abstractions.
