Documentation to address errors like "/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found"

I'm running into the error in the subject line when building locally and deploying in a docker container.

I can't tell if I need to do anything special to make rules_go build hermetically. Based on the output below, I'm guessing my host system's GLIBC is somehow affecting the binaries being compiled, but I'm not sure.

I thought rules_go and bazel mostly ignored the host system's installed libraries and toolchains. Maybe that is not the default behavior?

Relevant links:
1. [Examples on hermetic x86 cc_toolchains? on bazel-discuss](https://groups.google.com/g/bazel-discuss/c/kfWYRODXux4?pli=1)
2. https://github.com/bazelbuild/rules_go/issues/1642

GLIBC links:
1. https://github.com/bazelbuild/bazel/blob/master/tools/cpp/unix_cc_configure.bzl
3. https://bazel.build/tutorials/cc-toolchain-config
4. https://docs.bazel.build/versions/5.1.1/skylark/lib/cc_common.html#create_cc_toolchain_config_info documents target_libc with an example value of "glibc-2.2.2"
5. https://sourcegraph.com/search?q=context:global+target_libc&patternType=literal - tensorflow seems to define their own toolchains?
6. https://github.com/bazelRio/bazelRio/blob/1aad71917e2b4e372e295c015b82a8a79c721d2a/bazelrio/toolchains/roborio/toolchain_config.bzl

### What version of rules_go are you using?
v0.32.0

### What version of gazelle are you using?
v0.25.0

### What version of Bazel are you using?
7.1.1

### Does this issue reproduce with the latest releases of all the above?
Yes

### What operating system and processor architecture are you using?
Linux 22.04

### Any other potentially useful information about your toolchain?

Local execution but running the cgo binary I'm building on Kubernetes using this `rules_docker` rule:

```starlark
container_pull(
name = "golang_container",
registry = "index.docker.io",
repository = "golang",
tag = "1.18.2-bullseye",
)
```

### What did you do?

I used `rules_k8s` to deploy a program to a cluster using a locally built docker image. I can provide more details later on. The project I'm working in is a lot like this one, except it uses cgo: https://github.com/gonzojive/beam-go-k8s

```starlark
load("@io_bazel_rules_docker//go:image.bzl", "go_image")

go_image(
name = "my-image",
args = [],
#base = "@distroless//base:base_root_amd64_debian11",
#base = "@distroless//cc:cc_root_amd64_debian11",
#base = "@official_ubuntu//image",
base = "@golang_container//image",
binary = ":my-program",
goarch = "amd64",
goos = "linux",
)
```

my-image uses cgo

(I can provide more information if needed)

### What did you expect to see?

Successful program execution.

### What did you see instead?

Error when running the program in the cluster:

```
... /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /app/data/...)
... /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /app/data/...)
```

No target documentation file is named. Start by reviewing the linked Bazel unix_cc_configure.bzl, cc-toolchain documentation, and rules_go issue 1642, then compare them with the cgo, rules_docker, and golang_container setup shown here. Done means the relevant rules_go documentation clearly explains how to address this GLIBC mismatch scenario.

Written by the indexing model from the issue text.