<p>What are the practical differences between the two? When should I choose one over the other?</p>

<p>For example if I'd like to give a developer in my project access to just view the logs of a pod. It seems both a service account or a context could be assigned these permissions via a RoleBinding.</p>

<p><strong>What is Service Account?</strong></p>

<p>From <a href="https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/" rel="nofollow noreferrer">Docs</a></p>

<blockquote>
  <p>User accounts are for humans. Service accounts are for processes,
  which run in pods. </p>
  
  <p>User accounts are intended to be global...Service
  accounts are namespaced.</p>
</blockquote>

<p><strong>Context</strong></p>

<p><code>context</code> related to <code>kubeconfig</code> file(<code>~/.kube/config</code>). As you know <code>kubeconfig</code> file is a yaml file, the section <code>context</code> holds your <code>user/token</code> and <code>cluster</code> references. <code>context</code> is really usefull when you have multiple cluster, you can define all your <code>cluster</code>s and <code>user</code>s in single <code>kubeconfig</code> file, then you can switch between them with help of context (Example: <code>kubectl config --kubeconfig=config-demo use-context dev-frontend</code>)</p>

<p>From <a href="https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/" rel="nofollow noreferrer">Docs</a></p>

<pre><code>apiVersion: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
- cluster:
    insecure-skip-tls-verify: true
    server: https://5.6.7.8
  name: scratch
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: scratch
    namespace: default
    user: experimenter
  name: exp-scratch
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file
- name: experimenter
  user:
    password: some-password
    username: exp
</code></pre>

<p>You can above, there are 3 contexts, holds references of <code>cluster</code> and <code>user</code>.</p>

<blockquote>
  <p>..if I'd like to give a developer in my project access to just view the
  logs of a pod. It seems both a service account or a context could be
  assigned these permissions via a RoleBinding.</p>
</blockquote>

<p>That correct, you need to create <code>service account</code>, <code>Role</code>(or <code>ClusterRole</code>), <code>RoleBinding</code>(or <code>ClusterRoleBinding</code>) and generate <code>kubeconfig</code> file that contains service account <code>token</code> and give it your developer.</p>

<p>I have a <a href="https://github.com/veerendra2/my-k8s-applications/blob/master/spinnaker/kubeconfig_generator.sh" rel="nofollow noreferrer">script to generate <code>kubconfig</code> file,</a> takes service account name argument. Feel free to check out</p>

<p><strong>UPDATE:</strong></p>

<p>If you want to create <code>Role</code> and <code>RoleBinding</code>, <a href="https://github.com/veerendra2/my-k8s-applications/blob/master/spinnaker/spinnaker_sa.yaml" rel="nofollow noreferrer">this might help</a> </p>
