Cluster
You do not want to use this for sessions. It's not needed as sessions do not require high throughput. A cluster is also not highly available, and having keys spread out over multiple servers created more points of failure. This is acceptable for caching, but for sessions, this will require logging in again. This can be mitigated using slaves in the cluster, but has the same drawbacks as stated below. Also, you'll have to manage far more servers than with Redis Sentinel.
Master/Slave (with Sentinel)
Redis master/slave has master-only write, read-only slaves, with eventual consistency, and asynchronous replication.
For something not very intensive like sessions, and critical to user experience, I wouldn't read from slaves, however, as a new session may not be available on the slaves, which may cause some minor user experience issues with improper sessions.
Failover, on the other hand, can be beneficial for sessions. Any replicated sessions will still persist if the master were to fail.
Standalone
This is an alright option for small, sites that aren't part of a cluster (single server*), or sites where login information isn't critical to user experience or operations, such as only being necessary to post a comment on a blog that's publicly accessible. A simple "try again later" message will work.
The main advantage of this approach is that it's very simple to set up and maintain as it's a single installation. Redis is very stable, so you won't have issues with Redis itself often. Failures are more likely happen due to maintenance, updates, or server downtime than due to Redis itself failing.
*If you're using a single webserver in production for your business, Redis infrastructure should be the last of your concerns. Make it highly available.
Source: Built out infrastructure for a highly available WordPress site.