Usually, containerized applications, do not write to the log files but send messages to stdout/stderr, there is no point in storing log files inside containers, as they will be deleted when the pod is deleted.
What you see when running

kubectl logs -f <pod-name>

are messages sent to stdout/stderr. There are no container specific logs here, only application logs.

If, for some reason, your application does write to the log file, you can check it by execing into pod with e.g.

kubectl exec -it <pod-name> -- /bin/bash

and read logs as you would in shell.

Edit

Application logs

A container engine handles and redirects any output generated to a containerized application's stdout and stderr streams. For example, the Docker container engine redirects those two streams to a logging driver, which is configured in Kubernetes to write to a file in JSON format.
Those logs are also saved to

• /var/log/containers/
• /var/log/pods/

By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs.

Everything you see by issuing the command

kubectl logs <pod-name>

is what application sent to stdout/stderr, or what was redirected to stdout/stderr. For example nginx:

The official nginx image creates a symbolic link from /var/log/nginx/access.log to /dev/stdout, and creates another symbolic link from /var/log/nginx/error.log to /dev/stderr, overwriting the log files and causing logs to be sent to the relevant special device instead.

Node logs

Components that do not run inside containers (e.g kubelet, container runtime) write to journald. Otherwise, they write to .log fies inside /var/log/ directory.

Excerpt from official documentation:

For now, digging deeper into the cluster requires logging into the relevant machines. Here are the locations of the relevant log files. (note that on systemd-based systems, you may need to use journalctl instead)

Master

• /var/log/kube-apiserver.log - API Server, responsible for serving the API
• /var/log/kube-scheduler.log - Scheduler, responsible for making scheduling decisions
• /var/log/kube-controller-manager.log - Controller that manages replication controllers

Worker Nodes

• /var/log/kubelet.log - Kubelet, responsible for running containers on the node
• /var/log/kube-proxy.log - Kube Proxy, responsible for service load balancing

The only way I could imagine this to work is to make use of some external logging facility like Syslog or Elastisearch or anything else. Configure your application to send logs directly to logging facility (avoiding agents like fluentd or logstash which parse logs from files).

All modern languages have support for external logging. You can also configure Docker to send logs to syslog server.

Simple way to check log is kubernets:

=> If pod have single container

kubectl logs POD_NAME

=> If pod have multiple containers

kubectl logs POD_NAME -c CONTAINER_NAME -n NAMESPACE