Replication controller is only able to scale numbers of replicas of given pod and can't do any updates.

There is a way to "update" your ReplicationController using kubectl rolling-update, but it does not update it literally. That what is happening when you run kubectl rolling-update (link1):

1. Creating a new replication controller with the updated configuration.
2. Increasing/decreasing the replica count on the new and old controllers until the correct number of replicas is reached.
3. Deleting the original replication controller.

Rolling updates are initiated with the kubectl rolling-update command:

$ kubectl rolling-update NAME \
    ([NEW_NAME] --image=IMAGE | -f FILE)

Assume that we have a current replication controller named foo and it is running image image:v1 (link2)

kubectl rolling-update foo [foo-v2] --image=myimage:v2

If the user doesn't specify a name for the 'next' replication controller, then the 'next' replication controller is renamed to the name of the original replication controller.

Here are some more examples from the kubectl reference:

Update pods of frontend-v1 using new replication controller data in frontend-v2.json.

kubectl rolling-update frontend-v1 -f frontend-v2.json

Update pods of frontend-v1 using JSON data passed into stdin.

cat frontend-v2.json | kubectl rolling-update frontend-v1 -f -

Update the pods of frontend-v1 to frontend-v2 by just changing the image, and switching the # name of the replication controller.

kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2

Update the pods of frontend by just changing the image, and keeping the old name.

kubectl rolling-update frontend --image=image:v2

Abort and reverse an existing rollout in progress (from frontend-v1 to frontend-v2).

kubectl rolling-update frontend-v1 frontend-v2 --rollback

There are alternatives to the ReplicationController (link3)

ReplicaSet (Still it does not support updating Pod's image)

ReplicaSet is the next-generation ReplicationController that supports the new set-based label selector. It’s mainly used by Deployment as a mechanism to orchestrate pod creation, deletion and updates. Note that we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don’t require updates at all.

Deployment (Recommended) (It works as an orchestrator for ReplicaSets, so it supports updates by design)

Deployment is a higher-level API object that updates its underlying Replica Sets and their Pods in a similar fashion as kubectl rolling-update. Deployments are recommended if you want this rolling update functionality, because unlike kubectl rolling-update, they are declarative, server-side, and have additional features.

kubectl run nginx1 --image nginx --replicas=3
kubectl get deployment nginx1 --export -o yaml